u/Marmelab

So I recently inherited a legacy application that was a nightmare to maintain (tooling was clearly lacking and the codebase was pretty outdated). I quickly realized that if I ever wanted to actually enjoy working on it, I would have to give it a proper overhaul.

These are the 5 changes that had some of the biggest impact IMO:

1. uv:

Being new to the Python ecosystem, I didn't want to figure out pip vs poetry vs pyenv vs virtualenv, so I just used uv and let it handle all of that. One Rust-based tool that installs and pins Python versions, manages the venv automatically and locks deps in a uv.lock for reproducible builds. Installs are also a lot faster, which makes CI a lot less painful.

2. Ruff:

Coming from JS, I really missed eslint --fix for automatically fixing linting issues and format code on save. Ruff brought that experience back. I know that there are plenty of linters and formatters in the Python ecosystem, but this one really stands out for me. Since it's built in Rust, it's super fast.

3. Dependabot:

Instead of remembering to update dependencies every few months, I enabled Dependabot. It automatically opens PRs when updates are available and then CI tells me whether they're safe to merge. It takes only a couple of minutes to set up but saves a lot of maintenance.

4. Pylance:

Without it, VS Code gives generic completions and never warns you about passing the wrong type until runtime. Pylance provides proper type-aware autocompletion, jump-to-definition (even in third-party libraries), inline documentation, and real-time type checking. I personally keep it on "basic" mode for legacy codebases, since "strict" surfaced hundreds of errors (thank you, but no thank you lol).

5. Pydantic:

Pydantic is basically Python's Zod: you declare a model, pass your data in and get either a validated typed object or a ValidationError naming the exact field at fault. It really helped me keep the codebase clean, with one place defining the shape of the data instead of raw dicts floating around. I use it wherever data comes from outside, like API payloads, forms, and env vars with pydantic-settings, which fails at startup instead of mid-request.

None of these tools changed the application itself. But together they made working on it a lot less frustrating.

I recently inherited a legacy application that was a nightmare to maintain (tooling was clearly lacking and the codebase was pretty outdated).

These are the 5 changes that had some of the biggest impact IMO:

1. uv:

Being new to the Python ecosystem, I didn't want to figure out pip vs poetry vs pyenv vs virtualenv, so I just used uv and let it handle all of that. One Rust-based tool that installs and pins Python versions, manages the venv automatically and locks deps in a uv.lock for reproducible builds. Installs are also a lot faster, which makes CI a lot less painful.

2. Ruff:

Coming from JS, I really missed eslint --fix for automatically fixing linting issues and format code on save. Ruff brought that experience back. I know that there are plenty of linters and formatters in the Python ecosystem, but this one really stands out for me. Since it's built in Rust, it's super fast.

3. Dependabot:

Instead of remembering to update dependencies every few months, I enabled Dependabot. It automatically opens PRs when updates are available and then CI tells me whether they're safe to merge. It takes only a couple of minutes to set up but saves a lot of maintenance.

4. Pylance:

Without it, VS Code gives generic completions and never warns you about passing the wrong type until runtime. Pylance provides proper type-aware autocompletion, jump-to-definition (even in third-party libraries), inline documentation, and real-time type checking. I personally keep it on "basic" mode for legacy codebases, since "strict" surfaced hundreds of errors (thank you, but no thank you lol).

5. Pydantic:

Pydantic is basically Python's Zod: you declare a model, pass your data in and get either a validated typed object or a ValidationError naming the exact field at fault. It really helped me keep the codebase clean, with one place defining the shape of the data instead of raw dicts floating around. I use it wherever data comes from outside, like API payloads, forms, and env vars with pydantic-settings, which fails at startup instead of mid-request.

None of these tools changed the application itself. But together they made working on it dramatically more enjoyable.

What's the first thing you do when you inherit a legacy project?

Between AI agents running code on my machine and the recent npm package compromises I started feeling kind of uneasy about my local dev setup. So I gave devcontainers a proper try.

The idea is straightforward: your dev environment runs inside a container, fully isolated from your host. If something sketchy gets pulled in through a dependency, it stays sandboxed. That alone sold me. But the real win (didn't expect this one tbh) turned out to be onboarding. No more "which version of Node do you have?" conversations. You share the config, everyone gets the same setup. Done.

VS Code handles the container lifecycle pretty well, and once the initial image is built, startup is fast enough that it doesn't break my flow. So far so good.

The rough part turned out to be the documentation. Figuring out which variables apply where (image level vs. feature level vs. devcontainer.json) took way more trial and error than it should have. The spec is powerful but the docs kind of assume you already know what you're looking for. Not ideal when you're just getting started (famous last words, I kept telling myself "should be quick to figure out").

I'm sold enough to set them up on every project going forward. Next step is building custom images and features reusable across all our repos.

Anyone else found the docs painful to navigate, or did I just miss a good resource somewhere?

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 ;)

Google has silently stopped indexing pages on our website. There is no crawling error reported, no LCP problem, no canonical URL hiccup, no "written by AI" articles. They just decided, unilaterally, to drop arbitrary pages from their index.

"Crawled - currently not indexed" is growing with no explanation and no appeal possible.

We're not the only ones affected by this. Apparently, Google has decided that they no longer want to index the Internet. This appears to be in line with their recent announcement showing AI answers front and foremost in their user experience.

So what we find when searching in Google is now only a share of the Internet, the share they've decided is worthy of our attention. The rest is plunging into the "dark web".

Google doesn't pretend that they're sending back traffic anymore. Incoming traffic from Google search has dropped 50% in the past 6 months on our website. They just use the content they crawl to train their models, and they keep the traffic for themselves.

I find this concerning.

Is anyone here experiencing this?

https://preview.redd.it/c1l1a09eja3h1.jpg?width=991&format=pjpg&auto=webp&s=9d467b2665631fa0e6f54c79790acfc40a6e0ea8

Been keeping tabs on the open-source CRM space for a while. Here's a roundup of projects that have crossed the 1k GitHub star threshold, covering a decent range of use cases.

Project	Stars	GitHub
Mautic	7k	https://github.com/mautic/mautic
IDURAR	6k	https://github.com/idurar/idurar-erp-crm
YetiForce	1.8k	https://github.com/YetiForceCompany/YetiForceCRM
Krayin	1.1k	https://github.com/krayin/laravel-crm
Atomic CRM	1k	https://github.com/marmelab/atomic-crm

A bit more context on each:

Mautic - Sits closer to marketing automation than classic CRM, but covers leads, email campaigns, and multi-channel outreach with a full pipeline view.

IDURAR - MERN stack ERP/CRM covering customer management, invoicing, and quotes; aimed at small teams that want a full-stack JavaScript setup from day one.

YetiForce - Feature-dense PHP CRM targeting mid-size businesses, with modules for sales, support, accounting, and fine-grained role permissions.

Krayin - Laravel CRM focused on lead and pipeline management; a practical starting point for PHP teams that want something to fork and extend.

Atomic CRM - React-Admin-based CRM built for developers who want a clean, composable foundation to customize rather than a heavy opinionated product out of the box.

Anything worth adding? Would also be curious to hear what people are actually using for self-hosted sales pipelines at small team scale.

Last week I shared a post about some hidden commands that transformed my daily workflow in the terminal. I was honestly surprised to see how many people in this subreddit are also using the terminal over the desktop app. Thanks for sharing your experiences and other useful commands in the comments! I picked up quite a few things just from reading the replies.

Since people seemed to find it useful, I figured I'd share a few more underrated commands. So here we go:

• Visualize your context with /context: This gives you a clear view of what’s eating up your context. Once you start using it, you realize how fast things fill up, particularly across multiple files. (This is especially useful for whenever Claude starts acting weird lol).
• Keep your context clean with /compact: A full context uses up unnecessary tokens and reduces output quality. To prevent this, use /compact to summarize the conversation and keep only what matters going forward.
• Use /simplify after long coding sessions: After a lot of back-and-forth, the code can get a little messy (extra comments, TODOs, unnecessary complexity, etc.) /simplify looks at your last diff and refactors it without changing behavior.
• Track token usage with /usage: It shows a detailed breakdown of input and output tokens, cache reads/writes and total cost. Useful both for keeping an eye on expenses and for understanding how expensive different operations really are. I usually use it when a session starts feeling bloated. Bonus: you can add it to your status bar with something like: /statusline show token usage and cost

Thanks again for all the love on the last post! Love the community here

I needed an internal admin for a side project. The usual: list records, edit them, create new ones, etc. I've done this from scratch before with shadcn components and it works fine, but tbh, wiring up DataTables, forms, pagination, sorting, and hooking all that to a REST API by hand gets old fast. So I tried a different approach this time using Shadcn Admin Kit on top of TanStack Start.

The stack is @tanstack/cli create → tailwind → shadcn init → then one command to pull in the admin components:

npx shadcn@latest add https://marmelab.com/shadcn-admin-kit/r/admin.json

Plus ra-router-tanstack for TanStack Router compatibility. Took maybe 5 minutes to get to a working shell.

Now, here’s the part that surprised me. You point a <Resource> at an API endpoint, pass list={ListGuesser}, and it generates a working DataTable from the API response. It even logs the component code to the console so you can copy-paste it and start customizing. Same pattern for ShowGuesser and EditGuesser. Went from zero UI to a sortable, paginated user list in under a minute (not exaggerating for once).

The kit uses a "data provider" abstraction to talk to your API. There are pre-built adapters for common backends. I used ra-data-json-server for JSONPlaceholder during prototyping. Swapping to a real API later means replacing one adapter, not rewriting fetch calls everywhere. Smart pattern, though I haven't stress-tested it with a more complex API yet (nested resources, custom auth headers, etc.), so I can't say how smooth that transition actually is.

Once I replaced the guessers with real components, the full user CRUD (list + show + edit + create) fit in roughly 60 lines of actual code. <SimpleForm> and <TextInput> handle forms, delete comes for free on the edit view. It felt almost too easy (which usually means I'll hit a wall when I need something non-standard).

But I’m still unsure about customization depth. The default components look good (they're shadcn under the hood, so that checks out), but I haven't tried heavily overriding layouts or building a complex dashboard with custom widgets yet. Also, TanStack Start itself is still pre-1.0. The CLI warns you about it during install, so there's inherent risk there.

I put together a more detailed walkthrough with all the code snippets here.

Anyone here using shadcn for admin UIs?

I've been using Claude Code heavily in the terminal for the past 6+ months (as a Linux user you don't get the luxury of a dedicated Claude desktop app lol). But tbh what might seem like a constraint at first, really isn't (at least from my experience). If anything, it forced me to dig deeper into what Claude Code actually offers beyond the basic chat loop. And over time, I realized I'd been barely scratching the surface of what it can do.

Here are 5 hidden commands (or at least ones I completely missed at the beginning) that transformed my daily workflow:

• Customize your statusline with /statusline: I personally like having a persistent status bar that gives me key info at a glance, and this command adds exactly that at the bottom of your terminal. You can ask Claude to put whatever you want in it (model, branch, context % etc.).
• Run shell commands with !: You can run any shell command directly from the chat by prefixing it with !. The output stays in the conversation, so you can follow up without copy-pasting. Press Ctrl+B while a ! command is running to send (long-running) commands to the background.
• Mention files with @: Type @ + filename to trigger path autocomplete. This is way faster than letting Claude wander around your repo looking for the right file.
• Expand your working context with /add-dir: Add another directory to the session. Perfect for projects split across multiple repos.
• Start a side conversation with /btw: Ask a quick question without interrupting Claude's current task. For longer side discussions, you can use /branch to spin off a new session instead.

Tbh none of this is anything super fancy. But still, these small things have removed a lot of friction for me. Which commands are you guys using?

A few weeks ago, I shared some tips on my Claude Code workflow. In the comments, quite a few people mentioned that they were burning through their tokens super fast and tbh I could totally relate. This is something I particularly struggled with at the beginning, which pushed me to take a closer look at it. Turns out most of my token usage wasn't coming from Claude's answers, but from the setup.

Things I actually use:

• Start a new chat for unrelated tasks. Every message in a long conversation resends the full history. That's not obvious until I realize a 40-message thread is burning tokens on context I stopped caring about 20 messages ago.
• Group your small questions into one message. Sending three quick follow-ups instead of one combined message means three full context loads. I group them now and it adds up fast.
• Keep your CLAUDE.md short and use it as an index. I used to dump everything in there. The problem is Claude rereads it every single turn. Now it points to separate files and only loads what's relevant to the task.

Things I try to implement as much as possible:

• Be precise with file references. I used to say "here's the whole codebase, figure it out." Claude would spend 30-50k tokens just exploring before doing anything useful. Now I point it at the one function or module that actually matters.
• Summarize and restart after 15-20 messages. I ask Claude for a quick summary of where things stand, paste it into a fresh thread. I lose nothing and stop dragging dead context around.
• Use lighter models for lighter work. Not everything needs the heaviest model. Drafting, reformatting, explaining. I route those elsewhere and save the big model for the reasoning-heavy stuff.

What are your go-to tricks for keeping usage under control?

Last week I shared a post about my Claude Code workflow and some related tips, and to be completely honest, I didn't expect such a positive response! Thank you all for sharing your own tips in the comments, I learned quite a bit just from reading the replies.

Since people seemed to find it useful, I figured I’d share some more best practices. So here we go:

• Create skills for repetitive workflows. If I find myself repeating the same instructions, I turn them into a skill. The real trick is writing a precise description for it. That way, Claude eventually learns to trigger the skill on its own without me even asking.
• Use @ to point to files directly in your prompts. Instead of making Claude search around, just drop something like @/path/to/file.ts and Claude will load the referenced file directly into the context. Otherwise, Claude will have to look for the file and read it in chunks, which is a lot slower.
• Use ! to execute shell commands. If you need to launch tests or typecheck, it’s faster to type the CLI command than to ask Claude to do it.
• Keep CLAUDE.md short. I personally always aim for 200 lines or under. These 200(ish) lines should only include information that Claude couldn't possibly know on its own, such as your business context or domain knowledge (e.g. your data model, naming conventions, internal rules, etc.). Everything else is noise.
• Create an AGENTS.md file. Since AGENTS.md is the new standard for all coding tools, I put my core logic there (so it’s portable across agents). This way I can keep a short CLAUDE.md that simply imports it with @/AGENTS.md.
• Run the /security command: This command does a security review and should be run every once in a while. But don’t count on it to catch all vulnerabilities (it's still your job to guarantee the security of your code lol).

Thanks again for all the love on the last post!