标签：#Data

Nvidia invests $3.5 billion into Taiwanese chipmaker MediaTek. The deal shows how Nvidia plans to stay essential to AI infrastructure as Big Tech begins to build its own AI chips.

Dealing with multiple Excel or CSV files is a common task in business. Whether it is sales reports from different regions, customer data across various campaigns, or financial records by month, the need to combine these files into a single, cohesive dataset is constant. Manually copying and pasting or even using complex formulas can quickly become a time sink, prone to errors, and a source of frustration. What if you could automate this repetitive process? Imagine setting up a workflow that automatically merges your Excel files for you. That is where Microsoft Power Automate comes in. And when your data is messy, inconsistent, or riddled with duplicates, AI tools can take your automation to the next level. This guide will walk you through building robust workflows in Power Automate to combine your Excel workbooks. We will also explore how AI can address the often overlooked challenge of data cleaning and standardization, turning disparate data into a clean, unified source. Why Automate Excel Merges? The benefits of automating Excel data consolidation extend beyond simply saving time. Consider these advantages: Time Savings: Free up hours spent on manual data handling, allowing you to focus on analysis and strategic tasks. Reduced Errors: Eliminate human error from copy-pasting, formula mistakes, or missing data. Consistency: Ensure data is merged and formatted uniformly every time, regardless of who runs the process. Scalability: Easily handle increasing volumes of files without proportional increases in manual effort. Timeliness: Get up-to-date consolidated reports faster, enabling quicker decision-making. The Old Way: Manual Merges and VBA Limitations For years, consolidating data meant either painstaking manual copy-pasting, using VLOOKUP or INDEX/MATCH across sheets, or resorting to VBA (Visual Basic for Applications) scripts. Manual methods are slow and error-prone, especially with large datasets or many files. VBA offered a significant improvement, providing c

I had a PySpark job joining a large transactions table with a customer dimension table. Nothing exotic — a standard join, then an aggregation. On paper, it looked like it should scale fine across the cluster. In practice, the job would race through most of its tasks and then stall. The Spark UI told the real story: almost every task finished in a few minutes, but one or two tasks ran for over 40 minutes while their executors sat at 80–90% CPU, and the rest of the cluster sat mostly idle waiting for them to finish. This post walks through what data skew actually is, how I confirmed it was the cause, and the fix that brought the job back under control. What data skew actually is Data skew happens when one or a few keys hold a disproportionate share of the data. When Spark distributes work across partitions — usually via hash partitioning on a join or group-by key — all the rows for a given key land in the same partition. If one key has millions of rows and most others have a few thousand, that one partition (and the single task processing it) ends up doing far more work than every other partition combined. The result is a job where 95% of tasks look completely healthy, and the remaining 5% become the actual bottleneck. Total job time is dictated by the slowest task, not the average one — so a single skewed key can dominate your entire runtime even if it represents a tiny fraction of your total row count. How I confirmed it The Spark UI's stage view was the first clue: a chart of task durations with almost every bar clustered together, and one or two bars stretching far beyond the rest. That pattern — uniform short tasks plus one long outlier — is close to a signature for skew. To confirm which key was responsible, I ran a simple aggregation on the join key before doing anything else: from pyspark.sql import functions as F df . groupBy ( " customer_id " ) \ . count () \ . orderBy ( F . desc ( " count " )) \ . show ( 20 ) The output made it obvious: a small number of cu

If you've done LeetCode's Design HashMap , you've implemented put , get , and remove . What that exercise usually skips is the part that actually breaks in production: what happens when someone mutates the map while another piece of code is iterating over it. I ran into this directly while building MyHashMap , a from-scratch single-threaded HashMap (separate chaining, resize on load factor). Getting put / get / remove right was the easy 80%. Getting entrySet().iterator() to correctly detect concurrent mutation — including the case where a second, completely separate iterator is the one that should notice — took three wrong turns before landing on the pattern the JDK actually uses. The problem, concretely Iterator < Entry < K , V >> it = map . entrySet (). iterator (); it . next (); map . put ( someNewKey , someValue ); // structural change, mid-iteration it . next (); // ??? — undefined behavior if we don't guard against this Without a guard, next() might return a stale entry, skip entries entirely, or throw an unrelated exception depending on internal bucket-array state. Java's real collections handle this with ConcurrentModificationException (CME) — but the interesting part isn't the exception, it's the mechanism that detects when to throw it. First idea: a boolean "dirty" flag Obvious first attempt: a boolean modified field on the map, flipped to true on any put / remove , checked by the iterator. This works for exactly one iterator. It falls apart the moment two iterators are alive at once: Iterator A calls next() , sees modified == false , proceeds. Something else mutates the map. modified flips to true . Iterator B — created after that mutation — checks the same shared modified flag, sees true , and incorrectly throws, even though nothing has changed since B was created. A single shared boolean can't represent "changed since this specific iterator was created" for more than one iterator at a time. Resetting it on read doesn't help either — now the other iterat

Every lottery player knows the saying: "One line is no line, you have to play a few more to boost your chances!" That's why the average player often fills out a complete ticket with 8 lines. Sounds like a solid strategy, right? Wrong. It’s actually the fastest way to systematically burn through your cash. To prove it, we wrote a Python simulation that uses historical payout data and cold, hard combinatorics to see who actually has any money left in their account at the end. What exactly is a Monte Carlo simulation? Named after the famous casino in Monaco, the Monte Carlo simulation is basically the brute-force approach to probability theory. Usually, mathematicians use a single, elegant formula to calculate the expected value. That formula will dryly inform you: "You lose an average of 1 Euro per Eurojackpot line." That might be mathematically correct, but emotionally, it's a bit of a snooze. It doesn't capture the true pain of slowly bleeding out financially. The Monte Carlo simulation throws that elegant formula right out the window. Its core concept is pure, raw computing power. Instead of just calculating the theoretical outcome, we let the computer simply play through reality thousands of times. It’s not an equation; it’s a simulation and iteration of real events. The computer spawns 1,000 fictional players. For every player and every draw over the last 10 years, it generates a random number based on the actual Eurojackpot probabilities. It simulates the real-world winning and (mostly) losing, step by step. At the end, we aren't looking at some abstract theoretical number, but at the very real, blood-red bank accounts of 1,000 ruined clones. The Setup We're using Polars for lightning-fast data processing, NumPy to simulate millions of random draws, and Matplotlib to visualize our financial doom. First, grab our historical Eurojackpot database and drop it into the same folder. The Script Here is the complete Python code. It calculates the exact mathematical odds

As I have started my Data analysis and science curriculum, Microsoft excel is the first tool we have learnt. In my life before getting into this course, I used to underestimate the power of Microsoft excel. Definition of Microsoft Excel This is a spreadsheet software developed by Microsoft that allows you to collect, organize, analyze, calculate and visualize data efficiently. The Excel Interface When open Microsoft excel, you first an interface made of various tools We start with the ribbon. The ribbon contains a toolbar that contains all the commands organized into tabs such, Home, Insert, Page Layout , Formulas, Charts and Data There is a formula Bar that content and formulas appear. In addition, we have Quick access toolbar that contains icons for Save, Undo and Redo. A row is a horizontal line of cells that runs from left to right across the grid while a column is a vertical line of cells that runs from top to bottom down the grid. A cell is where row and column intersect and form a single box. Cleaning A Dirty Dataset As we learnt about Data cleaning with Excel on dataset that was a bit very disorganized. We first started with sorting that data which basically means arranging the data in specific order. The sorting can be Text sorting which is A-Z or Z-A, Number sorting which is from largest to small and vice versa, Date sorting which is Oldest to Newest and vice vera. Next was filtering which allows you display data that meet certain criteria and hide the rest temporarily. Next, Number formatting changes how numbers display without altering their actual value. Conditional Formatting highlights cells automatically based on rules or criteria, helping spot trends or outliers. The dataset we were cleaning had a lot of duplicates, so it was important for us to remove the duplicates. Text functions for Cleaning Data Text functions are used to remove extra spaces , standardize text ,extract parts of strings or find and replace sub strings. text functions include UPP

Every value in my little embedded key-value store gets encrypted, then its ciphertext gets encoded as a string of A/C/G/T characters before it ever touches the filesystem. Open the file in a text editor and you'll see actual DNA-looking text - not because it's a gimmick, but because that's genuinely the storage format. This is mdc-lite , a ~348KB embeddable encrypted key-value store I built in Rust for places a server can't reach - a watch face, a phone app, a background service. It's part of a larger repo, ModelDB , that also includes MDC, a Python conversational data engine (query AI models, databases, images, and documents in plain English, no SQL) with its own DNA-inspired archival storage tier. The actual storage format Every put() call does this, in order: Pack [key_len][key_bytes][value_bytes] into one plaintext buffer. Encrypt the whole thing with XChaCha20-Poly1305 (a 256-bit key you supply - the crate never generates or stores key material itself; real key custody belongs to the platform's secure hardware, iOS Secure Enclave or Android Keystore). DNA-encode the resulting [nonce][ciphertext][tag] blob: 2 bits per base, 00→A 01→C 10→G 11→T . Every byte maps to exactly 4 bases, so there's no padding ambiguity on decode. Write the ACGT text to disk, atomically (temp file + rename). Filenames are keyed BLAKE3 hashes of the logical key, not the key name itself, so a directory listing alone leaks nothing - no key names, no values, no way to tell how many distinct keys exist versus how many files are on disk. rust pub fn put(&self, key: &str, value: &[u8]) -> Result<(), LiteStoreError> { let mut plaintext = Vec::new(); plaintext.extend_from_slice(&(key.len() as u16).to_le_bytes()); plaintext.extend_from_slice(key.as_bytes()); plaintext.extend_from_slice(value); let nonce = XChaCha20Poly1305::generate_nonce(&mut OsRng); let ciphertext = self.cipher().encrypt(&nonce, plaintext.as_ref())?; let mut record = nonce.to_vec(); record.extend_from_slice(&ciphertext); let ac

The company is testing robots on tasks that can performed by technicians.

1. Introduction Excel is much more than a spreadsheet for entering numbers. It can be used as a data-analysis tool that helps analysts inspect, validate, filter, summarize, and prepare raw data before deeper analysis begins. In typical analytics, the quality of the final work depends heavily on the quality of the data used; therefore, data cleaning is not an optional step—it is the foundation of effective data analysis. This article demonstrates key Week 1 Excel concepts _using an employee dataset containing _employee IDs, names, departments, gender, marital status, hire dates, salaries, educational level, performance score among others. The raw file intentionally contains common data-quality issues: inconsistent capitalization on the First and Last names, blank records, duplicate employee records, varying department names, currency and dates that need review. By working through these issues, the article shows how Excel’s formatting tools, text functions, filters, conditional formatting, numerical functions, conditional summaries, and date functions can turn a messy workbook into an analysis-ready dataset. 2. Why Data Cleaning Matters Data cleaning is more than just about removing errors. By standardizing formats and categories, we make datasets more transparent, usable, and valuable for management analysis and reporting purposes. Data analysis is simple – garbage in, garbage out. A dashboard or prediction can appear professional, but can be misleading if the underlying data has duplicates, blank values, inconsistent categories or incorrectly formatted text and dates. For example, “IT” “I.T.” and “Information Tech” can be viewed as different department values if naming is not standardized. Duplication of an employee ID can inflate employee counts and department totals. A blank performance score might mean that something is missing and should be looked into and dates saved as text cannot be reliably used in calculations such as employee tenure checks. A good practice

Sometimes, a change that looks simple on the surface is not actually that simple. Imagine that you need to replace the source table feeding a refined or trusted table in a data pipeline. At first, it might look like a one-line change: update the table name, deploy the code, and move on. But in a real data platform, there is usually much more behind that change. There are dependencies, scheduling rules, upstream and downstream processes, resource consumption, concurrency, data lineage, and, sometimes, assumptions that were not immediately obvious when the pipeline was first created. I recently had to look into exactly this kind of situation in an Apache Airflow project, and one of the questions that came up was: Should this DAG be scheduled using a cron expression, or should it be triggered based on an Asset? The answer, as usual in software engineering, is: it depends. And understanding why it depends is much more important than simply knowing how to configure either option. Cron: the familiar way of scheduling a DAG Let's start with the simplest and most familiar option: a time-based schedule. With Airflow, we can define a DAG to run according to a cron expression: with DAG ( dag_id = " my_pipeline " , schedule = " 0 13 * * 0 " , catchup = False , ): ... In this example, the DAG is scheduled to run every Sunday at 1 PM. In a real environment, we might have different schedules for different environments. For example: Environment Schedule Development Saturday at 1 PM Homologation Sunday at 1 PM Production Monday–Friday at 1 PM The important characteristic here is that the schedule is based on time . If the DAG is configured to run at 1 PM every Sunday, Airflow will try to run it at that time, regardless of whether the data it depends on has actually changed. This is not necessarily a bad thing. In fact, sometimes this is exactly what we want. But there is another approach. When data becomes part of the schedule Modern data pipelines often have dependencies that are b

The second you hit Enter Friday night. You ask Cursor for a query: join orders to users, sort by last login. Three seconds later, an answer arrives with DBA-level confidence: SELECT o . id , o . amount , u . last_login_at FROM biz_order o JOIN sys_user u ON u . id = o . user_id ORDER BY u . last_login_at DESC ; Paste it into your client. Enter: ERROR: column "last_login_at" does not exist LINE 2: SELECT o.id, o.amount, u.last_login_at There is no last_login_at column. There never was. The model did not know — it just decided the column "should" exist. This failure has a name: invented column This is not "AI is not smart enough yet." It has a name — invented column : the model fabricates a plausible column name with no factual source, then writes it into a JOIN with unshakable tone. Invented columns are dangerous because they do not look like errors . last_login_at appears on 90% of user tables. Syntax is correct. Naming is conventional. Indentation is perfect. Mixed into ten correct JOINs, you will not catch it line by line. You find out in code review — or worse, in production logs. Three things you already tried A better prompt. "Do not invent column names; only use the schema I provide" — added to the system prompt. Works day one. By day three, long context and the model forgets. A prompt is a wish, not a constraint. @schema.sql . Export DDL and drop it into context. The most honest approach today — but two holes: it goes stale (last week's export does not know this week's column), and nobody maintains it (not in any approval flow; anyone can edit it; drift from the real database goes unnoticed). Live catalog MCP. Let the Agent query information_schema directly. Directionally correct — give the model a fact source instead of guesses. Tools like postgres-mcp and cloud vendor MCPs do solve half of "stop hallucinating column names." Worth acknowledging. Live catalog only gets you halfway Wire production into the IDE and you hit four walls: Permission-filtered inform

By Michael Nocito , data analyst · Published August 8, 2026 By the end of this page you will be running SQL directly against a CSV file on your machine, with no import step, no CREATE TABLE , and no schema written by hand. DuckDB reads the file where it lies, works out the column types itself, and gives you a normal SQL result. It takes one command to install and about a minute to prove. Here is what to actually do today. Run python -m pip install duckdb , then write a query with your CSV's filename in quotes where the table name would normally go. That is the entire idea, and everything else on this page is a consequence of it. The short version: a file is a table. It suits large files and folders of files, it does not replace SQLite for a shared database you keep, and section 6 says which to use when. The missing import step is the one idea worth the page, so it gets the picture. The original carries a diagram here. In words: Two horizontal sequences. The upper sequence runs through four stages joined by arrows: a file icon, then a box representing a schema being written, then a database cylinder, then a result grid. The lower sequence has only two stages joined by a single long arrow: the same file icon on the left and the same result grid on the right, with the middle two stages absent and the empty space where they used to be left visibly blank. Every output on this page is real. Run on 8 August 2026 with DuckDB 1.5.5 on Windows, against a 412-row CSV exported from the Chinook sample database. The numbers match the ones in the sample-database guide and the Python guide on purpose, because it is the same data through three different tools. 1. Install it Before the explanation: every database you have met so far needed you to create a table before you could put anything in it. What would have to be true for that step to be unnecessary? python -m pip install duckdb That is the whole installation. No server, no service running in the background, no configuration fi

By Michael Nocito , data analyst · Published August 8, 2026 By the end of this page you can load a CSV into pandas, find out in twenty seconds what type every column became, stop the identifier columns losing their leading zeros, get dates read the way they were written, and turn a money column that arrived as text into numbers. It is about twenty-five minutes, and every output below was produced by running the code. Here is what to do today, the moment after you first load a file. Run df.dtypes . Not df.head() , which shows you what the values look like, but dtypes , which shows you what they are. A column of identifiers that says int64 has already lost its leading zeros, and a money column that says object or str is text that will refuse to add up. The short version: read_csv reads characters and guesses a type per column. The guess is usually right, it is silent when it is wrong, and four arguments replace guessing with instruction. The same characters becoming two different values is the idea, so it gets the picture. The original carries a diagram here. In words: On the left, a strip of five small square boxes holds one character each, reading zero, eight, zero, five, three, as the characters appear in the file. Two arrows branch out from that strip. The upper arrow leads to a strip of five boxes in which the first box is empty, crossed through and outlined in amber, while the remaining four hold eight, zero, five and three; the leading character has been discarded. The lower arrow leads to a strip of five boxes holding zero, eight, zero, five and three, identical to the original, outlined in blue. Both destinations came from the same source strip, and only one of them still contains everything the file did. Every output on this page is real. Run on pandas 3.0.2 against a small CSV built to contain the four problems every real export has: an identifier with leading zeros, ambiguous dates, a text marker for missing values, and money with a thousands separator. If

About a year ago, I was building a terminal-based workflow manager called Glyph.Flow. It was mostly a learning project. I wanted to understand Python better, experiment with Textual, think about commands, state, configuration, logging, and all the small architectural decisions that suddenly appear when a script stops being a script. Somewhere between then and now, the workflows became a little more real. For my Master's thesis, I built a data pipeline to construct and process a cross-national research database from multiple sources. It had a clear purpose: take heterogeneous input data, transform it consistently, validate important assumptions, and produce the dataset I needed for the analysis. And it worked. But this is no longer enough. I am not rebuilding it because the original system failed. I am rebuilding it because the question changed: My Master's thesis needed a pipeline. My PhD will need research infrastructure. And I am slowly discovering that these are not the same thing. A pipeline can be finished There is something comfortable about building software for a well-defined research project. You know the research question. You know most of the variables you need. You know which datasets are involved. You can define the transformations, produce the outputs, validate them, run the analysis, and eventually say: Done. Of course, research is never really that clean. Data sources change. Weird edge cases appear. A country disappears from one dataset. Another source changes a variable name. An indicator turns out to mean something slightly different than you thought. But there is still a boundary around the problem. A PhD changes that boundary. Now I have to think about a system that may need to survive several years of research, new questions I have not formulated yet, datasets I have not discovered yet, and methodological decisions I will probably reconsider more than once. Suddenly, "Does it work?" becomes a surprisingly weak design criterion. The more useful

By Michael Nocito , data analyst · Published August 8, 2026 By the end of this page you can turn transactions into a monthly series, add period-on-period change and a cumulative total, get a share-of-total column, smooth a noisy line, and run all of it separately for every group. It is about twenty-five minutes, and every number below came out of running the code. Here is what to do today, on the series you already have. Count its rows against the number of periods in your date range. If your data covers January to May and the series has four rows, a period produced nothing, it never became a row, and every change figure after the gap is comparing the wrong pair. The short version: pct_change() divides each value by the one in the row above; cumsum() adds everything up to and including the current row. Both trust the rows you gave them to be the periods you meant. What happens when the previous period is zero is the idea, so it gets the picture. The original carries a diagram here. In words: Three bar positions stand on a baseline, labelled Mar, Apr and May. The March position holds a tall bar and the May position holds a slightly shorter tall bar. The April position holds no bar at all; there is only a short flat mark sitting on the baseline where a bar would start, drawn in amber to show a value of zero. An arc runs from the top of the March bar down to the April mark, and the figure minus one hundred percent is printed on it, which is a perfectly ordinary answer. A second arc runs from the April mark up to the top of the May bar, and the symbol printed on that one is not a percentage at all but the sideways figure eight that means infinity. The picture shows that a fall to nothing has an answer and a rise from nothing does not. Every number on this page is real. The sixteen-row orders table used across this whole set of guides, run in pandas 3.0.2. It runs from 5 January to 25 May 2026 and contains no April orders at all, which is not staged for this page; it is

By Michael Nocito , data analyst · Published August 8, 2026 By the end of this page you can attach columns from one DataFrame to another on a shared key, choose the right how for the question, see at a glance which rows failed to match, and catch the failure that quietly inflates every total in the frame. It is about twenty-five minutes, and every output below was produced by running the code. Here is what to do today, on every merge you write. Print the row count immediately before and immediately after it. A left merge must not change the row count, and if it did, the right-hand table has the key more than once and your totals have just gone up. The short version: merge pairs rows from two frames wherever their keys match, and the number of rows that come out depends on how many times each key appears on each side. One key twice on the right is the idea, so it gets the picture. The original carries a diagram here. In words: On the left a single row is drawn as a wide box, holding the key Desk and the value 880. To its right stands a small lookup table with two rows, and both of those rows carry the same key, Desk. Two lines run from the single left-hand row, one to each of the two matching lookup rows, so the one row is paired twice. On the far right the result is drawn as two separate output rows, and both of them contain Desk and 880; the value 880 is ringed in amber in each of them to show that it is the same original figure appearing twice. One row went in and two came out, without anything being added to the left-hand table. Every output on this page is real. Sixteen orders totalling 9,890 and a three-row product table, the same tables used across this whole set of guides, merged in pandas 3.0.2 with the results copied back. If you know SQL joins , this is the same operation with different words, and the two failure modes are identical. 1. merge in one line Two frames, one shared column, one call. orders.merge(products, on="product", how="left") order_id prod

Many engineers believe Common Table Expressions (CTEs) are always faster than subqueries. In modern SQL Server (and PostgreSQL), that is a myth . Here is what actually happens under the hood: 1. Inlining & The Query Optimizer By default, the SQL optimizer treats standard CTEs and derived tables (subqueries) almost identically: The engine expands both into the same relational tree. They generate the exact same execution plan and I/O cost . -- Pattern A: Derived Table (Subquery) SELECT DeptID , EmpName , Salary FROM ( SELECT DeptID , EmpName , Salary , DENSE_RANK () OVER ( PARTITION BY DeptID ORDER BY Salary DESC ) AS rnk FROM Employees ) RankedData WHERE rnk <= 2 ; -- Pattern B: Common Table Expression (CTE) WITH RankedData AS ( SELECT DeptID , EmpName , Salary , DENSE_RANK () OVER ( PARTITION BY DeptID ORDER BY Salary DESC ) AS rnk FROM Employees ) SELECT DeptID , EmpName , Salary FROM RankedData WHERE rnk <= 2 ; 2. When CTEs Truly Win: Readability & Pipeline Stacking: You can chain 5 CTEs sequentially without deeply nested pyramid brackets. In-Place Deduplication: In SQL Server, you can run DELETE directly on a CTE, and it deletes duplicate rows straight from the real underlying table! WITH DuplicateCleaner AS ( SELECT CustomerID , Email , ROW_NUMBER () OVER ( PARTITION BY Email ORDER BY RegistrationDate ASC ) AS rn FROM Customers WHERE Email IS NOT NULL ) DELETE FROM DuplicateCleaner WHERE rn > 1 ; -- ✅ Clean in-place deletion! 3. The Big Trap (Spooling Overhead): If you reference the same CTE multiple times in a query (e.g. CTE_A JOIN CTE_A ), SQL Server may execute the underlying CTE query multiple times or create a Lazy Spool in tempdb . -> Fix: For heavy multi-million row reuse, use a Temporary Table ( #TempTable ) with an explicit Clustered Index instead! 💡 How do you choose between CTEs, Temp Tables, and Subqueries in your pipelines? 💼 Connect on LinkedIn: linkedin.com/in/arpitmbangre

What Is Precision Tracking Radar? Precision tracking radar is an active radar sensing system designed to repeatedly measure a selected target and maintain an updated estimate of its state over time. For developers, the important distinction is that precision tracking is not simply repeated target detection. Detection answers: Is there evidence of a target in the current radar measurements? Tracking answers: Does this new measurement belong to an existing target, and how should that target state be updated? A practical precision tracking pipeline can be represented as: RF sensing → target measurement → detection → association → state update → continuous track → mission output That makes precision tracking radar a real-time data-processing system as much as an RF sensing system. A Practical Definition Precision tracking radar is a radar capability that combines repeated target measurements across time to maintain a continuous estimate of target position, motion or other relevant state information. The key word is continuous. A detector can operate independently on each radar update. A tracker has memory. It maintains information from previous measurements and decides how new observations relate to that history. From a software architecture perspective, tracking introduces persistent state into the sensing pipeline. Detection and Tracking Should Be Separate Services A useful radar architecture keeps target detection and target tracking logically separate. The detector processes current radar measurements. The tracker consumes target-related measurements over time. Conceptually: Radar measurement ↓ Detection ↓ Measurement object ↓ Association ↓ Track update ↓ Track state This separation helps developers understand where errors originate. If the detector produces unstable measurements, the tracker cannot fully repair them. If detections are stable but tracks switch between targets, the problem may exist in association. If sensor-relative detections are correct but missio

AI agents are becoming first-class citizens in developer workflows. They can read code, run tests, and deploy apps. But one thing they struggle with is understanding database schemas. Database design tools haven't changed in 20 years. You either use a heavyweight desktop app (Navicat, PDManer) or a pretty but closed web app (dbdiagram). Neither supports versioning, real-time collaboration, or AI agent integration. I built ERD Online to solve this. It's an open-source database design tool that combines Git-like versioning with Figma-like collaboration, plus MCP integration for AI agents. In this article, I'll show you how to let Cursor, Claude, or Cline read and write your database schema through MCP, while you keep full control. Database schema changes are hard to track: Who changed what? When did they change it? Why did they change it? How do I rollback? And now with AI agents, there's a new problem: how do you let an AI agent suggest schema changes without giving it a black box that generates random ER diagrams? The wrong approach: ask AI to "generate an ER diagram for an e-commerce app." You get a diagram, but it has no connection to your actual project, no versioning, and no approval flow. The right approach: let the AI agent read your existing schema, suggest changes, and submit them as a version that you review and approve. That's what ERD Online + MCP does. MCP (Model Context Protocol) is a protocol for AI agents to interact with external tools. Think of it as a USB-C port for AI applications. It standardizes how agents discover and call tools. MCP has three main primitives: Tools : Functions the AI can call (like list_projects or create_version ) Resources : Data the AI can read (like project.json ) Prompts : Pre-defined templates for common tasks ERD Online exposes MCP tools that let AI agents: list_projects : List all your ERD projects get_project : Get a project's projectJSON create_version : Suggest a new version of your schema The key boundary: AI agent

California residents have a legal right to access the data that companies collect about them. Actually exercising that right is a burdensome nightmare.