DEV Community: Karlis

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

Village Square: A Tiny Go‑Powered Hub for My Rural Community

Karlis — Sat, 28 Feb 2026 08:54:06 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built Village Square for my own rural village community.
Most people are neighbors, small local producers (fishermen, farmers, crafters), and families who meet several times a year, especially during our annual Village Day.

Right now, coordination happens through word of mouth, scattered chat groups, and printed posters. It’s easy to miss who is selling what, which events are happening when, or who needs help with something practical. Village Square tries to give us one simple place to share offers, requests, and Village Day activities.

What I Built

Village Square is a small community web app that acts like a digital village square. Logged‑in villagers can:

Register and log in with a simple account.
Post offers, requests, and announcements (e.g., fresh fish, potatoes, help with a fence, road closure).
Filter the feed by type and category (fish, produce, crafts, services, other).
Use a dedicated Village Day view to see garage sales, sports, and gatherings in a time‑based timeline.

For the challenge, I focused on a clean, mobile‑friendly interface and realistic seeded data so it feels like a real village snapshot rather than an empty prototype.

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

Demo

Here’s a short intro video of Village Square in action (login, feed, and Village Day screens):
https://github.com/user-attachments/assets/cd99a68b-b613-4101-8467-571a12c5924e

You can also run it locally:

Start the server and open http://localhost:8080.
Use the demo login: jan@village.nl / jan123.

Code

The full source code is on GitHub:

AcaciaMan / village-square

Digital village square for local announcements, garage sales, and connections between neighbors and suppliers.

Village Square

A community web app for a rural village — connecting villagers, local producers (fishermen, farmers, crafters), and the yearly Village Day celebration.

Built with Go (stdlib only) + SQLite + plain HTML/CSS/JS — no frameworks, no build step.

Short introduction video https://github.com/user-attachments/assets/cd99a68b-b613-4101-8467-571a12c5924e

Quick Start

# Prerequisites: Go 1.22+, GCC (for SQLite cgo)

# Clone and build
git clone https://github.com/<you>/village-square.git
cd village-square
go build -o village-square.exe .

# Seed with demo data (8 users, 18 posts, 6 events)
./village-square.exe --seed

# Start the server
./village-square.exe
# → http://localhost:8080

Demo login: jan@village.nl / jan123 (or any seeded user — see db/seed.go)

Features

Phase 1 — Foundation & Auth

User registration and login with bcrypt-hashed passwords
Server-side sessions via secure HttpOnly cookies
Auth guard on protected pages (auto-redirect if not logged in)
GET /api/me returns the current user

Phase 2 — Posts & Marketplace

Create, view…

View on GitHub

How I Built It

I wanted to keep the stack minimal and approachable for small communities to self‑host, so I went with:

Backend: Go standard library (net/http, database/sql, crypto/rand, bcrypt) with a small handler + middleware structure.
Database: SQLite via github.com/mattn/go-sqlite3, with migrations and a seeding command that creates demo users, posts, and Village Day events.
Frontend: Plain HTML, CSS, and vanilla JavaScript served from a /static folder (no frameworks, no build step).
Auth: Email + password with bcrypt hashing and server‑side session tokens stored in HttpOnly cookies, plus an auth guard for the dashboard and Village Day pages.

I structured the work in phases: foundation/auth, posts & marketplace, Village Day events, and finally polish/hardening (shared CSS/JS, toast notifications, responsive layout, logging, and limits). That made it achievable within a weekend while still feeling like a complete, coherent app for my village.

Since I had a bit more time, I didn’t just build a marketplace—I also added small features that nudge villagers to talk and help each other, like the new ‘I’m interested / I can help’ buttons.

My 60 USD/month dev environment (Copilot Pro, Claude, Gemini, Perplexity PRO)

Karlis — Wed, 25 Feb 2026 15:20:02 +0000

I’m an indie developer, and I wanted a reasonably priced, powerful setup for AI‑assisted coding that still keeps me in control of the work. After some experimentation, I’ve ended up with a roughly 60 USD/month stack that lives mostly inside VS Code and covers planning, coding, refactoring, and research.

The core stack

GitHub Copilot Pro – Inline completions, small refactors, and “fill in the obvious code” while I’m in the editor. It’s my default background assistant that keeps momentum going.
Claude Opus 4.6 – For higher‑level thinking: architecture discussions, planning the next steps, and non‑trivial refactors where I need long‑context reasoning and a more careful explanation.
Gemini 3.1 Pro – For alternative solutions and explanations. I use it when I want a second opinion on an approach, or a clearer explanation of complex code or algorithms.
Perplexity Pro (deep research) – For research and verification: comparing libraries, checking claims against multiple sources, and quickly collecting links I can inspect myself.

Open questions for you

Do you also stack multiple AI tools for development, or do you prefer going all‑in on a single provider?
How do you manage prompts and context across tools (especially inside an editor like VS Code) without drowning in windows and tabs?
If you had to cut this down to two AI services, which ones would you keep and why?

Drafted with the help of an AI assistant, edited by me.