Found this tool and I'm genuinely curious if it's worth it.

The idea is that it hooks into your coding agent and tags exactly which lines were AI-written, stored in Git Notes.

Survives rebases and merges apparently. There's also an ai blame command which I have to admit sounds kind of fun.

I mostly want to know if it actually changes how you work, or does it just sit there collecting data you never look at?

A while back I had to integrate data from a third-party REST API into a Postgres-backed app. My solution at the time was a cron job that periodically fetched the API, parsed the response, and shoved it into the database. It worked. It was also annoying to maintain and broke in creative ways. Months later I discovered that Postgres could have queried that API directly (and I felt a bit dumb lol).

The feature is called Foreign Data Wrappers, and it's been in Postgres for years. The idea: you create a virtual foreign table that maps to an external data source, then you query it with plain SQL. JOINs, WHERE clauses, INSERTs from SELECT, the whole deal.

Here's what I've been using it for:

**CSV files without the import dance **

Postgres ships with file_fdw. You point it at a CSV, define the columns, and it's a queryable table. You can JOIN it with your real tables or cherry-pick rows to INSERT into a permanent table. No more writing throwaway Python scripts to parse CSVs. One catch: file_fdw is read-only, so no writing back to the file.

Querying a remote Postgres database

postgres_fdw is also built-in. You set up a foreign server, map a user, create the foreign table, and suddenly you can query (and even UPDATE) another Postgres instance from your local one. Handy for migrations or cross-database reporting. Setting up the user mapping with credentials in plain SQL feels a bit rough, but it gets the job done.

**Talking to MongoDB (or any NoSQL store) **

This is where it gets fun. With Multicorn (a Python library) you can write your own FDW for pretty much anything. You define a Python class, implement an execute method that translates SQL qualifiers into queries for your target data source, and Postgres handles the rest. There are also ready-made FDWs for MongoDB, ElasticSearch, Redis, and others if you don't want to roll your own ;)

REST APIs as tables

Same principle with Multicorn. You write a wrapper class that turns WHERE clauses into API query parameters, hits the endpoint, and yields rows back to Postgres. I used the Magic: The Gathering API as a test case, nothing mission-critical, but the pattern translates to any REST endpoint. For authenticated APIs you just add headers or tokens in the Python code.

That said, it's not all smooth sailing. JOINs between foreign tables and local ones can get slow, especially with large external datasets. Also, debugging a misbehaving custom FDW is... not fun lol. And writing credentials in plain SQL for user mappings still makes me wince every time.

For those of you already running FDWs in production, how do you handle the performance tradeoff? Curious what strategies people have settled on ;)

A few months ago, I struggled with a planning system. I needed to ensure that no 2 plans could overlap for the same period. My first instinct was to write application-level validation, but something felt off. I thought to myself that surely PostgreSQL had a better way.

Turns out, PostgreSQL is packed with a bunch of underrated (and often simply overlooked) features that can save you from writing complex application logic:

1. EXCLUDE constraints: To avoid overlapping time slots

2. CHECK constraints: For validating data at the source

3. GENERATED columns: To let the database do the math

4. DISTINCT ON: Cleaner than a GROUP BY with subqueries

5. FILTER: To add a condition directly on the aggregate

Even after years of using it, I still discover features that make me question why I ever wrote complex application logic for things the database could handle natively.

I wrote an even more detailed version with examples (in case anyone thinks this isn't long enough lol)

Are there any other advanced PostgreSQL features I should know about?

I’ve spent years reaching for Makefile by default, but I recently started using Taskfile for my projects instead. While it’s still the industry standard, it often feels like a mismatch for the specific needs of a modern web stack… Since moving a few of my workflows over, I’ve found it much better suited for the way I work today.

Here are three features that convinced me:

=> Self-documenting by design

With Makefile, just getting a readable help output requires a cryptic grep | awk one-liner that’s been copy-pasted between projects for 40 years. Taskfile simply has a built-in desc field for each task, and running task --list instantly shows everything available with a clean description. It’s a small thing, but it makes onboarding new developers (or just returning to a project after a few weeks :) ) so much smoother.

=> Truly cross-platform without hacks

Make was designed for Unix. The moment someone on your team opens a PR from Windows, you’re suddenly wrestling with OS detection conditionals, WSL edge cases, and PowerShell compatibility. Taskfile was built cross-platform from day one. It uses sh as a universal shell by default, and if you do need platform-specific commands, there’s a native platforms field that handles it cleanly at the command level. No more fragile branching logic.

=> Built-in validation and interactive prompts

Adding a confirmation prompt or a precondition check in Make means writing verbose, bash-specific shell code that breaks outside of bash. Taskfile has prompt and preconditions as first-class features: one line to ask for confirmation before a deploy, another to verify an env variable is set. It works on every platform, out of the box, no shell scripting required.

In my opinion, Taskfile feels like a much more predictable and modern successor!

What do you think about it?

Ever get the feeling that modern web dev has become… a bit too complex?

Sometimes I catch myself thinking about the “good old days”. When you could just write some code, compile it, and run it without worrying about all the dependencies, the build tools, the client-side rendering, the server-side rendering, the server components, and all the other buzzwords that are thrown around in the web dev world… just code doing its thing.

And honestly, I think that feeling isn’t totally wrong. Maybe we can make things simpler, faster, more straightforward again.

So naturally… I decided to embrace the future by going back to the past: COBOL.

Here’s my (100% serious, definitely not questionable) migration story.

When I first started working on OSS projects, I really struggled with documentation. But after a lot of trial and error, I learned a lot about writing clear and helpful docs. Working on several OSS projects has also taught me just how essential good documentation is to the success of a project. So, I'd like to share with you some of the tips that have helped me improve (in the hope that they will save you the same headaches I've experienced lol):

• Guide first : Start with simple guides that focus on common use cases to help users get started quickly.
• Show, don’t tell: Use screenshots & screencasts early & often to visually demonstrate features.
• More code than text: Prioritize clear, working code examples over lengthy text explanations.
• Use plausible data: Craft realistic data in examples to help users better relate & apply them to their projects. I use faker.js for this.
• Examples as stories: Write examples in Storybook to ensure accuracy & consistency between code & visuals.
• The reference follows the guide: If an advanced user is looking for all possible options of a component, they can find them in the same place as the guide.
• Pages can be scanned quickly: Break content into short, digestible sections for quick navigation and easy reading.

Here's a doc example where I've tried to implement these best practices.

How do you approach documentation in your projects?