DEV Community: Karlis

Can We Quantify Political Clarity? An AI Experiment

Karlis — Mon, 07 Sep 2026 11:33:54 +0000

The Problem

Every election cycle, politicians make hundreds of promises. Some are specific: "Increase pensions by 50 euros by Q2 2027." Others are vague: "Strengthen our healthcare system." Most voters never know which candidates are actually committing to measurable goals versus just saying what sounds good.

This matters because specificity correlates with implementation capability. A candidate who names exact figures, timelines, and legislation can be held accountable. A candidate who speaks only in aspirations often cannot.

The question: Can we systematically measure this gap?

Introducing the Program Specificity Index

We built a framework that categorizes every policy claim into three tiers:

Concrete Plans (🟢): Specific numerical targets, exact timelines, named legislative acts, or measurable milestones. Example: "Cut corporate tax rate to 15% by 2027."

General Direction (🟡): Policy intent without implementation detail. Commitment exists but lacks numbers, timelines, or methods. Example: "Support small business growth."

Empty Slogans (🔴): Uncosted aspirations or emotional appeals too vague to be actionable. Example: "Build a brighter future."

Every claim in a political program gets assigned to one tier. The result: a "specificity score" (percentage of concrete claims) for each candidate or party.

What the Data Showed

We analyzed over 1,000 policy claims across a full slate of political programs and found:

Specificity varies wildly: Top performers scored 56% concrete claims; bottom performers scored 7%. This gap is meaningful.
Some sectors are always vague: Healthcare and education promises were systematically less specific than tax or defense promises, regardless of who made them.
Family benefits dominate concrete language: Pension and child-benefit pledges consistently included exact euro amounts. When politicians want to show specificity, this is where they do it.
Party age matters: Newer, single-leader parties averaged much higher specificity scores than long-established coalition parties, which relied heavily on abstract phrasing.
Universal boilerplate exists: Across all parties, identical defense spending commitments ("5% of GDP") appeared verbatim. Same language, different lips.

How We Built This: The Technology Stack

The analysis pipeline relied on three layers of AI:

1. Text parsing and claim extraction: We fed entire political programs to Claude Sonnet (Anthropic's mid-tier model, optimized for reasoning) to parse natural language and extract distinct policy statements. The model filtered out meta-commentary, introductions, and repeated phrasing to identify unique claims worth categorizing.

2. Multi-tier classification: Each claim was classified by Sonnet using the three-tier framework. The model applied consistent logic: Does this claim contain at least one concrete element (a number, date, percentage, or specific action)? If yes: 🟢. If it names intent but lacks implementation detail: 🟡. If it is pure aspiration: 🔴.

3. Sector tagging and aggregation: Every claim was also tagged by policy domain (Economy, Healthcare, Education, Defense, Social Protection, etc.). This allowed us to measure specificity not just by party, but by sector within each party. We aggregated counts, percentages, and patterns across all 1,000+ claims to generate summary statistics.

The entire workflow ran in a single pipeline: parse → categorize → tag → aggregate → summarize. Sonnet's reasoning capability was essential because political language is slippery. The model had to distinguish between "we will raise pensions" (general direction) and "we will raise pensions by 50 euros" (concrete plan). That nuance requires understanding, not just keyword matching.

Why This Matters

This framework demonstrates that AI can be applied to civic accountability. Instead of relying on journalist instinct or voter intuition, we used systematic analysis to measure a concrete property of political communication: specificity.

The method is replicable. Any country running an election can apply this same framework to their own candidates or parties. The three-tier system is universal. The AI pipeline is straightforward. The results are transparent (every claim can be reviewed).

More broadly, this shows how LLMs can be used for data journalism and civic tech. The model does not make judgments about right or wrong policy. It measures an objective property: Is this claim specific enough to implement and verify?

Apply This to Your Elections

If you are running an election in your country, you can replicate this analysis. The framework needs:

Full text of candidate or party programs (in any language Claude understands).
Clear definitions of what "concrete," "general," and "vague" mean in your political context (adapt the examples).
A few minutes of AI API time to run the classification.

The output: A ranked list of candidates or parties by specificity score, plus sector-level breakdowns showing which policy areas get concrete treatment and which are left vague.

This is useful for voters. It is also useful for researchers studying how political communication changes over time or across regions.

What would you measure if you built this for your own elections?

Fixing Boring Playoff Brackets: Why Injecting 1–2 Random Games Skyrockets Tournament Hype

Karlis — Mon, 31 Aug 2026 01:30:14 +0000

Every developer building a tournament engine or game format hits the exact same wall: Standard static brackets are predictable.

In a traditional 8-team single-elimination bracket, Seed #1 plays Seed #8, Seed #2 plays Seed #7, and so on. Mathematically, it's fair. From a broadcast and engagement perspective, it’s a snoozefest. Early rounds are plagued by predictable blowouts, and 90% of the tournament's hype is backloaded into the Semifinals and Finals.

To fix this, many system designers suggest blowing up the bracket entirely—switching to full double-elimination, multi-tier group pots, or complex ladder systems. But you don't need to rebuild the wheel.

The most effective solution is micro-targeted: Inject just 1 or 2 randomly assigned games into the early playoff rounds while keeping the rest of the system rank-seeded.

The Concept: "Controlled Volatility"

You do not need to randomize the entire tournament, nor do you need to convert your league into a complex pot-based group stage.

Instead, you keep standard regular-season rankings as the baseline, but inject 1 to 3 randomized wildcard games in the opening phase of the postseason.

How It Works in an 8-Team Playoff

The Rank Protection (1 Game):

  * **Seed \#1 vs Seed \#8** remains statically locked.
  * *Why?* Top seeds earned their advantage during the regular season, and bottom seeds shouldn't get a free pass.

The Controlled Randomness (2 Games):

  * Instead of automatically pairing \#2 vs \#7, \#3 vs \#6, and \#4 vs \#5, place **Seeds \#2, \#3, \#4, \#5, \#6, and \#7** into a live, randomized lottery pool.
  * Draw 3 matches randomly from this pool.

               [ 8 PLAYOFF TEAMS ]  
              /                   \  
 [ Top & Bottom Seeds ]       [ Mid-Table Seeds ]  
      (#1 & #8)             (#2, #3, #4, #5, #6, #7)  
          │                            │  
          ▼                            ▼  
 FIXED RANK MATCHES            RANDOMIZED LOTTERY  
  • Match 1: #1 vs #8           • Match 2: Random Draw A  
                                • Match 3: Random Draw B  
                                • Match 4: Random Draw C

By randomizing just 1 or 2 early matches, you instantly transform predictable mid-table fixtures into explosive, high-stakes coin-flips without burning top-seed regular season value.

Algorithmic Implementation (Python Engine)

If you are writing a tournament routing engine, combining deterministic seeding with a randomized early-round pool is straightforward:

import random  

class Team:  
    def __init__(self, name: str, seed: int):  
        self.name = name  
        self.seed = seed  

class ControlledVolatilityBracket:  
    def __init__(self, teams: list[Team]):  
        # Requires 8 teams ordered by seed 1 to 8  
        self.teams = sorted(teams, key=lambda t: t.seed)  

    def generate_round_1_matchups(self) -> list[dict]:  
        matchups = []  

        # 1. Deterministic Lock for Seed 1 vs Seed 8  
        matchups.append({"type": "Seeded", "home": self.teams[0], "away": self.teams[7]})  

        # 2. Random Lottery Pool for Seeds 2-7  
        random_pool = self.teams[1:7]  
        random.shuffle(random_pool)  

        # Draw 3 randomized matches  
        for i in range(0, 6, 2):  
            matchups.append({"type": "Random", "home": random_pool[i], "away": random_pool[i+1]})  

        return matchups

Real-World Case Studies: Does Randomness Actually Work?

We don't have to guess whether early-stage randomness increases viewership—major sports and esports leagues have already proven it:

1. League of Legends Worlds (The Swiss Stage Shift)

In 2023, Riot Games ditched static groups in favor of a Swiss Stage, where teams with identical win-loss records are drawn randomly live on stream in early rounds.

The Result: Viewership during the opening randomized days broke historical broadcast records. Viewers tuned in en masse because marquee top-tier teams could randomly collide on Day 1 rather than waiting for the Semifinals.

2. UEFA Champions League (The Hybrid 8-Game Phase)

Starting in 2024, European football replaced static 4-team groups with a single 36-team league phase where each team plays 8 games. While teams are seeded into pots, software randomly selects their specific 8 opponents.

The Result: Broadcasters reported massive year-on-year increases in viewership hours during early rounds. Randomly forcing heavyweight clubs to meet early eliminated the traditional "dead phase" of early-season group play.

3. English FA Cup (The Open Random Draw)

The world's oldest soccer tournament uses an unseeded, completely open random draw for every single round.

The Result: It creates two of the most popular broadcast tropes in sports: The Giant-Killing (an amateur club randomly drawing a giant at home) and The Early Blockbuster (two title favorites colliding in Round 1).

Why 1–2 Random Games Solve the Hype Dilemma

From a system architecture and behavioral psychology standpoint, injecting minor randomness delivers three key wins:

Eliminates the "Dead Phase": Standard brackets treat Round 1 as procedural filler. Randomizing 1 or 2 matches brings marquee intensity to Day 1.
Generates Free Broadcast Content: The "Draw Event" (spinning a wheel or drawing balls live on TV) becomes a standalone broadcast spectacle that drives social media engagement before a single game is played.
Preserves Competitive Integrity: Because top seed #1 maintain the earned matchup against lower seed, the regular season still matters. You get the hype of randomness without the unfairness of a pure lottery.

Final Thoughts

You don't need a convoluted bracket shape to make playoffs interesting. By blending 75% rank-based stability with 25% controlled randomness, you eliminate predictable filler, increase early-round screen time, and create a system that caters to both competitive purists and casual fans.

How do you handle tournament seeding in your projects? Would you introduce random lottery matches into traditional brackets, or do you prefer pure deterministic trees? Let's discuss in the comments.

AI generated test cases to improve application stability

Karlis — Fri, 07 Aug 2026 11:06:12 +0000

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

AI suggestion

Now my side projects I develop using AI. Usual prompt for me is to ask how to improve the project. Usually one of the suggestions is to add more tests. I am a developer and not a tester, therefore to do the good necessary test coverage part I leave to AI. As for me, application testing is not trivial and I accept that each one can develop his/her own testing strategy and it is totally fine.

Acacia-Log example and gained experience

For example, Acacia-log project. First time AI generated a lot of tests Added testing and improved performance. The generated tests did not find any bugs (AI has hard job at finding bugs in it's own code), but further development improved by far. After each feature addition, AI is able to do improved testing and early catch changes that broke previous logic.

Screenshot of AI adding new features (last step is doing verification):

Example of the prompt for Phase 5 generation:

Practicing “Database Insights”: where to find real schemas?

Karlis — Tue, 05 May 2026 11:55:25 +0000

We talk a lot about “data-driven decisions”, but that usually hides three separate layers:

Data itself (events, transactions, logs, etc.).
Database structure (schemas, constraints, relationships).
Insights on top (from SQL, AI copilots, BI tools, notebooks).

My current interest is in that middle layer: using real-world database structures as a playground to practice database insights:

Understanding and improving data quality (missing constraints, odd cardinalities, misuse of types).
Suggesting schema improvements for future analytics (indexes, normalization vs denormalization, slowly changing dimensions, etc.).
Making access easier via views, semantic layers, or documentation (ERDs, db docs, column descriptions).

I’m looking for good open source repositories that contain:

Non-trivial database schemas (preferably SQL migrations or DBML, not just ORM models).
Some realistic sample data if possible (to check cardinalities, null patterns, etc.).

I’m collecting good open-source schemas to practice database insights; here’s what I’m looking for and I’d love your suggestions.

Do you know specific GitHub repos with interesting database schemas (preferably with migrations + demo data) that are good for practicing:
- data quality checks,
- schema critique,
- documentation and visualization?
Have you tried using AI tools on top of real schemas to propose constraints, rename columns, or design better access patterns? How did that go?

Drop any links or examples you have – especially repos where the schema itself is a central part of the project.

Acacia DB for VS Code: Map your database usage in source code (1.0.0 1.2.0)

Karlis — Thu, 30 Apr 2026 12:25:11 +0000

If you've ever inherited a legacy system and asked "which tables are actually used, where, and how do they connect?" — that's the question Acacia DB tries to answer.

It's a VS Code extension that scans your workspace for references to database tables and columns, then turns the raw matches into something you can navigate, rank, and diagram. No LLMs, no cloud calls — just a deterministic pipeline over your source tree and a tables_views.json schema file.

The last three releases (1.0.0, 1.1.0, 1.2.0) reshaped the extension from a workspace scanner into a small analysis suite. Here's what landed.

1.0.0 — The pipeline rewrite

1.0.0 is the first stable release. The headline change is that the column-relationship analysis pipeline was rewritten end-to-end for both performance and correctness.

Parallel column-link analysis. Column matching now runs in a worker_threads pool (min(cpus, 8) workers), with an in-process async fallback when the worker bundle isn't available. File I/O and matching overlap across cores instead of stalling on a single thread.

Targeted line scanning. Workers no longer read every line of every file. They open only the line numbers already recorded in table_refs.json for each file, so the second pass costs a fraction of the first.

One global matcher instead of many. Previously a fresh column matcher was rebuilt per table and per file. Now a single matcher is built once at the start of analysis and shared across all workers.

Trie-level fast paths.

An ASCII first-character bitset gives O(1) reject for non-candidate characters before any trie walk.
The matcher operates on charCodeAt directly instead of text.split('').
The quote-skip state machine is bypassed on lines with no " or '.
On rejection, the matcher skips the rest of the current word in one pass.

Pre-filter for impossible files. Files whose in-scope tables can't contribute at least two candidate columns are skipped before any I/O.

O(1) link recording. Each LinkedTableInfo now carries a Map<key, ColumnLink> plus per-link/per-info Set<string> file caches, so recordColumnLink is O(1) per call instead of O(k) over the link array and O(n) over the file array.

Correctness fix: case-sensitive matching with shared lowercased prefix. Adding two column names that lowercased to the same string (e.g. "ABC" and "abc") used to clobber each other on the shared trie path — case-sensitive lookup could return the wrong canonical name or no match at all. Each terminal node now stores all case variants, and case-sensitive lookup resolves to the variant that actually appears in the text.

The dead pairwise per-file analyzer and the legacy processLines / processFileStream / processLine helpers were removed; the orchestrator now drives a single unified pipeline.

1.1.0 — Hot-Path analysis and a leaner JSON format

1.1.0 added an insight layer on top of the raw usage index, and reshaped the persisted analysis file.

Hot-Path Analysis

A new module, src/hotPathAnalyzer.ts, exposes pure functions: computeTableMetrics, computeEdgeMetrics, suggestIndexes, suggestCaches, and buildHotPathReport.

Per-table metrics: usageCount, fileFanOut, joinDegreeIn/Out, weighted PageRank centrality, and a tunable hotScore:

$$\text{hotScore} = \log(1 + \text{usageCount}) \cdot (1 + \text{joinDegree}) \cdot \sqrt{\text{fileFanOut}}$$

Per-edge metrics: coOccurrenceCount, linkConfidence, and edgeScore = coOccurrenceCount * linkConfidence.

Suggestions:

Index suggestions for join keys on top-quantile edges, emitted as ready-to-paste DDL: CREATE INDEX IX_<table>_<col> ON <table>(<col>).
Cache suggestions for read-heavy leaf tables (high usage, low join degree).
Cold-table report (usageCount === 0).

A Hot Paths tree view in the sidebar surfaces five sections: Top Hot Tables, Top Join Paths, Index Suggestions, Cache Candidates, and Cold / Unused Tables. Hot-table and edge leaves reveal the related table in the Database Explorer; index suggestions support a Copy DDL context action.

New commands: acacia-db.exportHotPathReport, acacia-db.hotPath.refresh, acacia-db.hotPath.diagnose, acacia-db.hotPath.copyIndexSuggestion.

Configuration lives under acaciaDb.hotPath.*: topN, weights.usage, weights.joins, weights.fanOut, minLinkConfidence, indexSuggestionQuantile, cacheCandidateQuantile, cacheCandidateMaxJoinDegree. Changing any setting refreshes the view without a reload.

Relationship-only filtering

A new filterToRelationshipsOnly setting saves only references that participate in table relationships. On large codebases this drops file size by 80–95% and is enabled by default. Tables with zero references are no longer saved or shown.

The filtering algorithm itself was rewritten: complexity went from roughly O(n² × m²) to O(n×m + f×r log r + f×r×w) by grouping references per file, sorting for early termination on proximity checks, and skipping single-table files. Filtering time on a 477-table codebase dropped from 10–20 s to 0.5–2 s. Results are cached after the first computation, so the JSON export no longer re-runs the filter.

File-based JSON format

The persisted table_refs.json was reorganized from table-keyed to file-keyed: each entry is a file with a list of references (line, column, tableName). The new shape is ~40% smaller, doesn't trip JSON.stringify on very large workspaces, loads faster via direct object access, and diffs cleanly in version control. Relationships are simplified to table pairs and counts.

Tree-view sorting was tightened across all levels — files by reference count, relationship files by instance count, proximity instances by distance (closest first) — while the JSON keeps an alphabetical file order for stable diffs.

1.2.0 — Heatmap and Mermaid ER export

1.2.0 adds two visualization paths over the data Acacia DB already collects.

Database Usage Heatmap

src/heatmapView.ts renders a tables × files matrix in a webview panel:

SVG with a log/linear color-scale toggle and adjustable cell size.
Hover tooltip showing table, file, and reference count.
Click-to-open: jumps to the first line where the table appears in the file.
Row totals on the right and column totals on the bottom as bar sparklines, plus a legend gradient with min/max.
Driven by the in-memory tableUsageMap, with .vscode/table_refs.json as a no-scan fallback.
Truncation warning when the matrix exceeds the configured caps.

Caps are configurable: acaciaDb.heatmap.maxTables (default 50, max 1000) and acaciaDb.heatmap.maxFiles (default 100, max 2000). Tables and files are ranked by total reference count before truncation.

The command acacia-db.showUsageHeatmap is wired into the Database Explorer view title bar.

Mermaid ER Diagram Export

src/mermaidErExport.ts exposes a pure buildMermaidEr function (no vscode import) that turns detected column relationships into a Mermaid ER diagram:

Relationships are deduplicated by unordered table pair, and forward / backward / bidirectional directions are aggregated into a single Mermaid cardinality (}o--||, ||--o{, or }o--o{).
Optional per-entity column blocks pulled from tables_views.json, capped per table for readability.
Identifiers are sanitized for Mermaid's [A-Za-z_][A-Za-z0-9_]* rule; columns named PK / FK / UK are renamed (PK_col, etc.) to avoid colliding with Mermaid's reserved attribute-key tokens.

Three export targets via Quick Pick: open as Markdown preview, save to .vscode/erDiagram.md, or copy Mermaid source to clipboard. The command acacia-db.exportMermaidEr lives on the Column Explorer view title bar.

Configuration: acaciaDb.mermaidEr.maxTables (60), acaciaDb.mermaidEr.omitIsolated (true), acaciaDb.mermaidEr.includeColumns (true), acaciaDb.mermaidEr.maxColumnsPerTable (20).

Try it

Marketplace: manacacia.acacia-db
Repo: github.com/AcaciaMan/acacia-db

Point it at a tables_views.json and a source folder, run the analysis, and you'll get a usage tree, a relationship graph, hot-path suggestions, an ER diagram, and a heatmap — all from the same scan, all stored locally in .vscode/.

Feedback and issues welcome.

Building Repo Promoter Agent for the DigitalOcean Gradient™ AI Hackathon

Karlis — Thu, 09 Apr 2026 08:39:55 +0000

I recently participated in the DigitalOcean Gradient™ AI Hackathon with a project I’m pretty excited about — Repo Promoter Agent. The idea came from a simple but recurring problem: promoting open-source projects on GitHub is often harder than building them.

💡 Inspiration

As someone who maintains several open source repositories, I noticed that my projects often struggle to reach the right audience. Writing promotional content — tweets, summaries, posts — takes time that could otherwise go into building features. I wanted a tool that could take a repository URL and instantly generate reusable marketing copy for it.

🚀 What It Does

Repo Promoter Agent does exactly that. Paste any public GitHub repo URL into the app, and it generates a complete promo pack:

A catchy headline
A short summary and key benefits
Tweet-sized snippets
A LinkedIn-style post
A call to action

All generated content is stored, indexed, and searchable — so you can quickly reuse good material across different projects.

🧩 How I Built It

The app combines several components:

Frontend: A simple web UI with “Generate” and “Search” screens
Backend: Written in Go, it fetches repo data and structures input for the AI agent
AI Layer: A Gradient AI agent processes the input and returns well‑structured JSON output
Search Engine: Apache Solr 10 indexes the generated content for fast retrieval

Once the agent returns the JSON promo pack, it’s stored and instantly searchable in Solr.

🧠 What I Learned

Using DigitalOcean’s Gradient AI platform was surprisingly smooth. The key insight was to think of prompt design as a contract — if the backend can trust the JSON format, the rest of the pipeline becomes predictable. It’s a great exercise in bridging LLM creativity with backend reliability.

⚙️ Challenges

Getting Solr 10 configured correctly took significant tuning, especially for schema and query logic. Another tricky aspect was finding the right balance between AI creativity and structure — ensuring the agent’s output stayed valid JSON without sounding robotic.

💰 Costs

Here’s what the first day of testing looked like:

App (29 hours): $1.07
Droplet (34 hours): $1.62
Database (58 hours): $1.69
Agents: $0.15

Total: $4.53 for a live day of experimenting. The cost will increase as I test more agents and models.

🛠️ Built With

GitHub
Go
Solr
Gradient AI

If you want to explore the project or see it in action, check out the Devpost page here.

How can we effectively combine Go, TypeScript, Python, and WebGL in a single application?

Karlis — Thu, 02 Apr 2026 11:04:43 +0000

I’ve been thinking about how different programming languages shine in their own areas:

Python is perfect for scientific computation, machine learning, and quick prototyping.
TypeScript dominates when building rich web or desktop apps (and has great tooling through VS Code).
Go is excellent for backend services, concurrency, and deployment speed.
WebGL (via JavaScript or TypeScript) makes it possible to render interactive graphics and video directly in the browser.

Each of these ecosystems is powerful on its own — but real-world applications often need the strengths of several. For example:

Using Python for AI model inference,
Go to handle fast concurrent servers,
TypeScript/WebGL for an interactive front end.

So here’s the core question:

What are effective modern strategies, tools, or architectures for connecting these languages together in one cohesive project?

I have a few ideas, but I’d love to get insights from others who’ve built multi-language systems:

Should something like gRPC/Protobuf be the glue between Go and Python?
Can we use WebAssembly (WASM) to share logic between browser and backend?
What about using message queues (e.g., Redis, Kafka) for structured language-agnostic communication?
Are there practical workflows to make multi-language development not a maintenance nightmare?

Any examples, open-source frameworks, or architectural patterns would be really helpful.

Acacia Log 4.0.0 – Stop Grepping, Start Navigating Your Logs

Karlis — Tue, 24 Mar 2026 17:18:58 +0000

Working with logs should feel like debugging, not archaeology.

Most of us still scroll, grep, and mentally replay a system’s history from a flat text file where the only real structure is the timestamp and the fact that lines arrive in order.

Acacia Log is a Visual Studio Code extension that leans into that simple idea: logs are time-ordered records with timestamps, so let’s treat them as a queryable time series instead of a wall of text.

Version 4.0.0 is out now, and it turns that idea into a full workflow for navigating, visualizing, and comparing massive log files without leaving VS Code.

What is Acacia Log?

Acacia Log is an advanced log file analyzer and visualizer for VS Code.
It helps you navigate huge .log, .txt, .jsonl, and .ndjson files by timestamp, detect time gaps, visualize activity timelines, search with regex patterns, analyze similar lines, and compare multiple files – all inside the editor.

Key capabilities:

Jump directly to any timestamp using binary search on the log’s time index.
Visualize activity as interactive bar, area, or line charts with zoom and pan.
Find the most frequent messages via structural “similar line” grouping.
Search multiple regex patterns in parallel and see counts + charts.
Compare throughput and latency across 2–20 log files.
Convert between JSONL/NDJSON and plain-text logs with guided wizards.
Supports 20+ timestamp formats with automatic detection (ISO, Apache, Syslog, Log4j, Windows Event Log, UNIX timestamps, and more).

If your logs have timestamps and grow over time, Acacia Log treats them like a time-series you can explore.

If you end up using Acacia Log 4.0.0 in your own debugging, DevOps, or performance workflows, I would love feedback to keep improving the time-based analysis features.

Weather‑Smart Merchandiser: Using Notion MCP + Claude to Turn DIY Sales & Weather Data into Layout Actions

Karlis — Fri, 06 Mar 2026 18:41:41 +0000

This is a submission for the Notion MCP Challenge

What I Built

I built Weather‑Smart Merchandiser, a weather‑driven merchandising tool that analyses historical sales–weather data, forecasts demand by temperature bucket, and then generates store layout‑change suggestions for a DIY store.

Under the hood, it’s a Python project exposed as an MCP server, so AI assistants (like Claude Desktop) can call high‑level tools such as layout_actions or top_categories instead of manually running scripts. The workflow is: the assistant looks at recent DIY sales and temperatures, classifies upcoming days as cold / mild / warm, and then proposes concrete layout moves (e.g., “move garden tools to front endcap for the warm weekend” or “highlight insulation at the entrance for a cold spell”).

On top of that, I use a Notion workspace as the control center:

A “Sales & Weather (Daily)” database holds the input data.
A “DIY Categories & Layout” database describes where each category currently lives in the store.
A “Layout Actions” database is automatically populated by the MCP tools with suggested moves, dates, and expected uplift.

The result is a small but realistic “weather‑smart” merchandising assistant for a DIY store that feels like a real workflow, not just a toy script.

Incremental updates

I am used to develop things incrementally. As there is still time left in the challenge, I will improve the solution and in this section will write my updates.

First incremental update: Added a Kanban view to the Layout Actions database in the DIY dashboard. Now store managers can instantly see actions flowing from Planned → In Progress → Done at a glance, making the workflow feel even more production-ready.

Added SQLite database for Python MCP server

Switched from CSV to JSON data exchange format: Discovered an issue. FastMCP's _convert_to_content function iterates over list results and converts each item separately into its own TextContent block. So when your tool returned list[dict], each dict became a separate JSON text block — producing {...}{...}{...} (concatenated objects) instead of {...}, {...}, {...}. The fix: all three tools (demand_signals, forecast, layout_actions) now return json.dumps(result, indent=2) — a single JSON string that FastMCP wraps in one TextContent block. Restarted Claude Desktop to pick up the change.

Added Sales insights subpage in DIY dashboard: Added also Claude Desktop prompt in GitHub repository to fill in Sales insights subpage.

Video Demo

https://github.com/user-attachments/assets/bdb07f87-5e2a-4974-be23-12ba47560132

Public Notion project page:
https://neighborly-fridge-ea2.notion.site/Weather-smart-merchandiser-31a4fffb13a880618b7fd4198be66b30

Public Notion DIY dashboard:
https://neighborly-fridge-ea2.notion.site/DIY-Weather-Smart-Merchandising-fffb7fe844f841bda431202321e29ac9

I recorded a short video walkthrough showing:

How I trigger the workflow from Claude Desktop by asking: “Generate layout actions from Sales & Weather for the next 3 days and write them into Notion.”
How the MCP server returns suggested actions (per store, date, category, and temperature bucket).
How Claude then uses Notion’s MCP integration to create new rows in the “Layout Actions” database and generate a “Store Playbook” summary page in Notion.
How I can also ask Claude to summarize the weekend layout actions into a concise briefing, so store staff get a quick “weekend plan” without reading every individual row.
The final Notion DIY dashboard that shows weather, recent sales, and planned layout changes in one place.

Show us the code

The full source code is available here:

GitHub repo: https://github.com/AcaciaMan/weather-smart-merchandiser

Key pieces:

first_python_module.py – core library with reusable functions for:
- loading the sales_weather_daily.csv dataset
- computing demand signals by temperature bucket
- generating a simple forecast
- producing layout‑change suggestions
server.py – MCP server entry point that wraps these functions as MCP tools.
sales_weather_daily.csv – example dataset with Date, Store, Temp °C, Weather, Category, Units Sold, Revenue €.
requirements.txt – Python dependencies.

You can run it in three ways:

As an MCP server from a client (e.g., Claude Desktop).
With an MCP inspector / dev CLI for testing.
As a standalone script to generate layout actions into layout_actions_suggested.csv.

How I Used Notion MCP

My goal was: say one prompt, get real layout actions written into Notion automatically, and optionally get a weekend summary.

I used Notion’s MCP integration together with my custom Python MCP server so an AI assistant can orchestrate the whole chain:

Custom MCP server (Python)
- I implemented tools such as:
  - list_stores – list unique stores in the dataset.
  - demand_signals – average units sold per temperature bucket and category.
  - top_categories – top sellers for cold / mild / warm conditions.
  - classify_temperature – classify any °C value into a bucket.
  - forecast – a simple temperature forecast for upcoming days.
  - layout_actions – an end‑to‑end tool that takes a store and days‑ahead and returns layout suggestions.
- This server runs locally and is registered as a custom MCP server in my client.
AI client (Claude Desktop) calls the MCP tools
- From Claude, I can ask:
  - “For store ‘Riga 1’, generate layout actions for the next 3 days based on the existing sales_weather_daily.csv data.”
  - “Summarize this weekend’s layout actions into a short briefing for store staff.”
- Claude calls my layout_actions tool, which:
  - reads the CSV (or, in a more advanced setup, reads from Notion)
  - computes demand signals per temperature bucket
  - fakes or consumes a short‑term forecast
  - outputs structured layout actions (Store, Start/End Date, Category, Suggested Move, Expected Uplift, Forecast Temp, Bucket).
- Then, using the actions already written into Notion, I can ask Claude to summarize the weekend plan, producing a concise natural‑language overview (“This weekend: promote Garden and Cooling near the entrance, de‑emphasize Insulation”).
Notion MCP writes the results into Notion
- In the same conversation, I ask Claude to “take these layout actions and insert them into my Notion ‘Layout Actions’ database, and create a summary page.”
- Using Notion’s MCP integration, Claude:
  - creates new rows in the Layout Actions database (one per suggested move)
  - updates or creates a “DIY Weather‑Smart Merchandising” dashboard view
  - generates a “Weekend Store Playbook” page summarizing:
  - upcoming temperature buckets
  - key categories to promote
  - concrete moves for staff
  - a short summary of the weekend layout actions.
Why Notion MCP matters here

Notion MCP turns Notion into the front end for the system:

I don’t have to build a custom UI; everything lives in Notion pages and databases.
The AI can both read (past actions, sales context) and write (new layout actions, summaries) in a structured, permission‑aware way.
My Python MCP server stays focused on the “brains” (weather + sales logic), while Notion is the “workspace” where humans see and act on the plan—and even get an auto‑written weekend summary they can quickly share with the team.

What do you do when your side project has almost no users?

Karlis — Wed, 04 Mar 2026 16:55:03 +0000

Imagine you build a side project for people on the internet, but almost nobody uses it for a long time. What do you do next? Take a break, put it away, change its name, or try something else?

As AI boosts developer productivity, how will expectations change?

Karlis — Tue, 03 Mar 2026 17:04:51 +0000

With AI accelerating coding and debugging, I’m curious how this will reshape expectations for developers. Will roles shift toward higher-level problem solving and system design, or will productivity gains mainly raise delivery pressure and standards?

Bringing Local Slalom Races Online with Canoe Slalom Live

Karlis — Sun, 01 Mar 2026 13:57:23 +0000

This is a submission for the DEV Weekend Challenge: Community.

The Community

Canoe and kayak slalom has a strong grassroots scene: small clubs, volunteer judges, parents on the riverbank, and athletes who travel long distances for a single race run. Yet many local events still run on paper start lists, handwritten penalties, and spreadsheets that never leave the timing laptop.

I built Canoe Slalom Live for that community: local organizers who want something lightweight they can run on a single laptop at the course, judges who need a simple way to record runs, commentators who want quick access to athlete stories, and spectators who just want to understand what is happening on the water in real time.

What I Built

Canoe Slalom Live is a tiny live-timing and results web app for canoe/water slalom competitions. It runs as a Go web server with an embedded SQLite database and server-rendered HTML, so an organizer can start it on a laptop at the riverside and let everyone else follow the event from their phones.

The app provides a public event page with a start list grouped by category, a live leaderboard with penalties, a photo gallery, dedicated commentator and athlete profile views, plus a mobile-friendly judge panel for entering runs and penalties. It focuses on making results understandable for spectators while giving judges and commentators tools that fit how small events actually work.

It’s a single Go + SQLite binary that can run on a small VPS or services like Google Cloud Run.

Demo

GitHub repository (code + README + screenshots):

AcaciaMan / canoe-slalom-live

Weekend-built sports app for canoe/water slalom meets. Supports creating events, managing start lists and athlete bios, recording runs and penalties, and showing a live leaderboard for the whole community.

🛶 Canoe Slalom Live

Live timing and results for canoe/water slalom competitions. Built for grassroots events — run it on a laptop at the riverside, let spectators follow on their phones.

Short introduction video https://github.com/user-attachments/assets/90fe481d-032e-493f-acd4-5c0e1be7cca1

Quick Start

# Prerequisites: Go 1.22+, GCC (for SQLite CGo driver)
go mod tidy
go run main.go -seed

# Opens at http://localhost:8080
# Judge panel at http://localhost:8080/judge/events/demo-slalom-2026

To enable authentication for judge routes:

# Windows
set ADMIN_TOKEN=secret123
go run main.go -seed

# Linux/macOS
ADMIN_TOKEN=secret123 go run main.go -seed

# Judge panel: http://localhost:8080/judge/events/demo-slalom-2026?token=secret123

Stack

Go — net/http with Go 1.22+ pattern routing, html/template for server-rendered HTML
SQLite — embedded via github.com/mattn/go-sqlite3 (CGo), WAL mode, single data.db file
Vanilla HTML/CSS/JS — no build step, no framework, no bundler

It’s a single Go + SQLite binary that can run on a small VPS or services like Google Cloud Run.

Pages

Route	Page	Description
`/events/{slug}`	Event	Start list grouped

…

View on GitHub

Short intro video (live walk-through of the seeded demo event):
https://github.com/user-attachments/assets/90fe481d-032e-493f-acd4-5c0e1be7cca1

To try it locally:

bash
go mod tidy
go run main.go -seed
# Opens at http://localhost:8080
# Judge panel at http://localhost:8080/judge/events/demo-slalom-2026

Code

The full source code is available here:

AcaciaMan / canoe-slalom-live

Weekend-built sports app for canoe/water slalom meets. Supports creating events, managing start lists and athlete bios, recording runs and penalties, and showing a live leaderboard for the whole community.

🛶 Canoe Slalom Live

Live timing and results for canoe/water slalom competitions. Built for grassroots events — run it on a laptop at the riverside, let spectators follow on their phones.

Short introduction video https://github.com/user-attachments/assets/90fe481d-032e-493f-acd4-5c0e1be7cca1

Quick Start

# Prerequisites: Go 1.22+, GCC (for SQLite CGo driver)
go mod tidy
go run main.go -seed

# Opens at http://localhost:8080
# Judge panel at http://localhost:8080/judge/events/demo-slalom-2026

To enable authentication for judge routes:

# Windows
set ADMIN_TOKEN=secret123
go run main.go -seed

# Linux/macOS
ADMIN_TOKEN=secret123 go run main.go -seed

# Judge panel: http://localhost:8080/judge/events/demo-slalom-2026?token=secret123

Stack

Go — net/http with Go 1.22+ pattern routing, html/template for server-rendered HTML
SQLite — embedded via github.com/mattn/go-sqlite3 (CGo), WAL mode, single data.db file
Vanilla HTML/CSS/JS — no build step, no framework, no bundler

It’s a single Go + SQLite binary that can run on a small VPS or services like Google Cloud Run.

Pages

Route	Page	Description
`/events/{slug}`	Event	Start list grouped

…

View on GitHub

Key routes:

/events/{slug} – event overview with start list and athlete bios
/events/{slug}/leaderboard – live leaderboard with auto-refresh and penalty sparklines
/events/{slug}/photos – photo gallery with photographer credits
/events/{slug}/commentator – big-screen commentator view
/events/{slug}/athletes/{id} – athlete profile with run history and linked photos
/judge/events/{slug} – judge panel for recording runs (auth-protected via admin token)

How I Built It

Stack and architecture
I used Go 1.22 with net/http pattern routing and html/template for fully server-rendered pages, backed by a single SQLite database file accessed through github.com/mattn/go-sqlite3. There is no build pipeline or frontend framework: just vanilla HTML, CSS, and a tiny bit of JavaScript for auto-refresh.

The project is split into small packages: domain for core types (events, athletes, runs, sponsors, photos), store for SQLite queries, and handler for public and judge HTTP handlers plus authentication and logging middleware. Templates live in templates/ and are composed around a shared layout with a simple nav bar linking Event, Leaderboard, Photos, and Judge.

Data model and scoring

The SQLite schema has seven tables: events, categories, athletes, entries, runs, sponsors, and photos. Entries link athletes to an event and category with a bib number; runs store raw time, touches, missed gates, and computed total time, and a UNIQUE(entry_id, run_number) constraint prevents duplicate runs. Scoring follows standard ICF rules: +2 seconds per gate touch, +50 seconds per missed gate, ranking athletes by their best single-run total time.

UX for each role

For spectators, the leaderboard auto-refreshes every 10 seconds and highlights medals, “NEW” runs, time-behind-leader, and tiny CSS sparklines that compare raw time vs penalties. Commentators get a dedicated view that shows the latest result in huge type with bio and penalties plus current top three for each category, optimized for projection. Judges use a mobile-friendly panel with large tap targets, penalty steppers, confirmation before saving, recent runs, and run-status indicators so they can work quickly in a noisy outdoor environment.

Safety and polish

To keep things safe without overbuilding auth, judge routes are protected with an ADMIN_TOKEN environment variable and a simple session cookie once the token is used. There is server-side validation for time ranges and maximum penalties, basic security headers, and structured request logging with method, path, status, and duration. I also seeded a complete demo event (Demo Slalom 2026) so anyone cloning the repo can see realistic data, categories, and sponsors immediately