DEV Community: Lawrence

Shopping for Skills and MCP Servers (Without Getting Burned)

Lawrence — Wed, 07 Oct 2026 05:01:35 +0000

A year or two ago, giving an AI assistant new abilities meant waiting for the company behind it to ship a feature. Now it feels more like wandering through a market. There are directories full of MCP servers, there are piles of skills on GitHub, and every week someone posts a shiny new one that will supposedly change how you work. I like this a lot, but I've also learned that browsing it is a skill in itself. Like any market, there are real finds, there are things that look good on the shelf and are useless at home, and there are a few things you really shouldn't put in your basket.
First, a quick word on what you're actually shopping for, because the two things get mixed up constantly. An MCP server is a connection. It's what lets an assistant reach out to something beyond the chat: your calendar, a database, a code host, a project tracker, a folder of files. MCP stands for Model Context Protocol, and the whole point of it is that one standard way of plugging things in means a server written once can work with many different assistants. A skill is something different. It's know-how. At its simplest it's just a folder with a text file called SKILL.md that explains how to do a certain kind of task well, sometimes with templates or scripts alongside it. The assistant reads a short description of each skill, and when your request matches one, it pulls in the full instructions. So an MCP server gives the assistant hands, and a skill teaches it how to use them well. The best setups I've seen use both together: a connection to your tracker, plus a skill that explains how your team likes tickets written.
Where do you shop? For MCP servers, the closest thing to an official storefront is the MCP Registry, a community-run directory that launched in preview in September 2025. It's less a store than a catalogue of listings, and the actual code lives elsewhere, in places like npm, PyPI or Docker Hub. At last count, one guide put it at nearly two thousand servers, which is plenty to get lost in. On top of that sit lots of other directories that pull from it and add their own ratings or curation, and they're worth browsing, though their quality bar varies a lot. Skills are scattered more widely. Because the format is simple and has been picked up by other tools, not just Claude, you'll find them in vendor repositories, plugin marketplaces and community directories that claim tens of thousands of entries. Many companies also publish their own official skills and servers for their own products, and those are usually where I'd start.
Now for the part that matters most, which is how to tell a good find from a dud. My first question is always who made it and whether they're still around. A server from the company that runs the service in question is a very different thing from a weekend project by a stranger, and a repository that hasn't been touched in a year may quietly stop working the next time the underlying API changes. Stars and download counts help a little, but I'd rather see recent commits and people actually responding to issues.
My second question is what it can do, and here MCP servers deserve more suspicion than skills. A server runs code, often on your machine, and it's usually holding a key to one of your accounts. That means it's worth reading the list of tools it exposes before you connect it. Does a note-taking server really need to delete things? Does a read-only task need write access? If there's an option to limit it, I limit it, and I give it the narrowest token I can get away with. There's a second, sneakier issue too: the text a server returns, such as an email or a web page, gets read by the assistant, and a malicious bit of text can try to give it instructions. This is one reason I'm cautious about connecting an assistant to a lot of untrusted content and a lot of powerful actions at the same time.
Skills feel safer at first glance, since they're mostly just words, and the great thing is that you can read one in two minutes. Do that. Open the SKILL.md and check that it says what the listing claims. The description at the top matters most, because it decides when the assistant will reach for the skill. A vague one gets triggered at the wrong moments or never at all. Also look for any scripts bundled in the folder, because those do run, and they deserve the same scrutiny as any code you'd download.
There's one more thing I've learned the hard way: resist the urge to hoard. It's tempting to install everything that looks interesting, but every tool and every skill description takes up space in what the assistant has to keep in mind. Load up forty servers and the assistant has to pick between overlapping tools, and it often picks worse. Two tools that do nearly the same thing are a recipe for confusion. I'd rather have a small kit that I trust and understand than a huge one I can't keep track of.
So my routine is simple. Start from a problem I actually have, not from what's trending. Look first at official offerings from the service involved. Check who maintains it and how recently. Read what it can do, and give it the least access that works. Try it on something low-stakes. And if it earns its place after a week or two, keep it, and if it doesn't, remove it without guilt. The market is only going to get bigger and noisier, and I think the people who get the most out of it won't be the ones who install the most, but the ones who choose carefully and keep their kit small.

Docker: The Tool That Ended "It Works on My Machine"

Lawrence — Mon, 05 Oct 2026 07:59:50 +0000

Every developer has said it at least once: "But it works on my machine." Maybe your laptop had a slightly different version of Python, or a library installed months ago that you forgot about, or a database configured just so. The code was fine. The environment was the problem, and nobody could tell you exactly how the two differed. Docker is the tool that made me stop having that conversation, and it's one of the few pieces of technology I'd call a genuine turning point in how software gets built and shipped.
So what is Docker? At its simplest, it's a way of packaging an application together with everything it needs to run: the code, the runtime, the libraries, the system tools, the settings. That package is called an image, and when you run an image, you get a container. A container is an isolated little world where your app runs, and it behaves the same on your laptop, on your colleague's laptop, on a test server and in production. You build it once and run it anywhere Docker is installed.
People often compare containers to virtual machines, and the comparison is useful up to a point. A virtual machine carries an entire operating system inside it, which makes it heavy, slow to start and hungry for memory. A container shares the host's kernel and only packages what the app itself needs, so it's much lighter. Containers start in a second or two instead of a minute, and you can run dozens on a laptop without it complaining. The isolation isn't as strict as a full VM, but for most day-to-day work that trade is more than worth it.
The background is a nice story. The ideas behind containers were around long before Docker. Linux had been growing features like namespaces and control groups for years, which let you wall off processes from each other, and earlier projects had built on them. But using those features directly was fiddly and the preserve of experts. Docker came out of a company called dotCloud, and it was shown to the public in 2013, built by a team that included Solomon Hykes. What they did wasn't invent containers so much as make them pleasant. They gave people a simple command line, a clean way to describe an image in a text file, and a place to share images, and suddenly everyone could use something that had previously been for a few specialists. It spread incredibly fast, and today the container format has been standardised by the wider industry, so Docker is no longer the only tool that can run these images.
The heart of the everyday experience is the Dockerfile, a short text file that describes how to build your image. You say what to start from, copy in your code, install your dependencies and say what command to run. That's it. Because the file is just text, it lives in Git next to your code, and anyone can read it to understand exactly how the app is put together. I love that. The setup instructions that used to live in someone's head, or in an out-of-date wiki page, become something that runs. Images are built in layers too, so Docker can reuse the parts that haven't changed, which keeps rebuilds quick once you've got the hang of ordering your steps sensibly.
Why do I think it's great? For me it comes down to a few things. The first is onboarding. A new teammate used to spend a day or two fighting with installation instructions, and now they run a command or two and the whole project is up. The second is consistency, which is the "works on my machine" problem finally put to bed, because the machine is shipped along with the code. The third is how well it plays with others. With Docker Compose, you can describe your app, a database, a cache and a queue in one file and start the lot with a single command, which makes local development feel almost unfairly easy. And the fourth is that it became the foundation for a lot of modern infrastructure. Tools like Kubernetes exist to run and manage huge numbers of containers, and learning Docker is the natural first step into that whole world.
It's not perfect, of course, and it would be dishonest to pretend otherwise. Images can balloon in size if you're careless. Containers are disposable by design, so anything you want to keep, like database files, needs to live on a volume or you'll lose it when the container goes away. Security needs real thought, because running everything as root or pulling random images from the internet is a bad habit. And Docker has a learning curve of its own: networking and volumes confuse almost everyone at first. There are alternatives too, like Podman, that some people prefer for various reasons. None of this changes my view, though. The problems it causes are far smaller than the ones it solves.
If you've never tried it, the best way in is small. Install Docker, run a ready-made image like a database or a web server, and watch it appear in seconds with nothing left cluttering up your machine afterwards. Then write a Dockerfile for a tiny project of your own. Somewhere around that moment, I think, you'll feel the same thing I did, which is the quiet relief of knowing that what you built is going to run the same way everywhere.

DBML: The Small Language I Wish I'd Found Sooner

Lawrence — Mon, 05 Oct 2026 07:38:28 +0000

If you have ever tried to explain a database to someone who didn't build it, you know the pain. You open a file full of CREATE TABLE statements and watch their eyes glaze over. Or you dig up an entity-relationship diagram someone drew eighteen months ago, and it turns out half of it no longer matches reality. DBML is the thing that finally made this problem feel solvable to me, and I think it deserves a lot more attention than it gets.
So what is it? DBML stands for Database Markup Language. It's a small, plain-text language for describing a database: your tables, their columns, the indexes, and how everything relates to everything else. You don't run it against a database. You write it, and other tools read it and turn it into diagrams, documentation or actual SQL. Here's roughly what it looks like:

Table users {
id integer [primary key]
email varchar [unique, not null]
}

Table posts {
id integer [primary key]
title varchar
author_id integer [ref: > users.id]
}

Read that and you've basically understood the whole idea. Two tables, a few columns, and that little ref: > users.id saying many posts belong to one user. There's no ceremony and no wall of syntax to wade through.
The background is pretty interesting, because DBML didn't come out of a standards committee. It came out of Holistics, a company that makes business intelligence software and spends its days working with other people's data models. They built dbdiagram.io, a web tool where you type on the left and a diagram redraws itself on the right, and DBML was the language powering that. It caught on among developers who just wanted to sketch a schema quickly, and the team then open-sourced the language and its parser so it wasn't tied to a single product. Since then a little ecosystem has grown around it: a command-line tool that converts between DBML and SQL in both directions, a JavaScript library for parsing it, and dbdocs.io for publishing your schema as a browsable documentation site.
Now, why do I think it's great? Mostly because it's readable by everyone. A backend engineer, a data analyst and a product manager can all look at the same DBML file and follow it, which means modeling mistakes get caught in conversation instead of in production. The relationship symbols are a big part of that. One character tells you whether something is one-to-many, many-to-one or many-to-many, and once you've seen them a couple of times you stop thinking about them.
I also love that it's just text. A text file lives happily in Git, so a schema change shows up in a pull request as a few readable lines, and someone can say "should this really be nullable?" before a single migration gets written. Compare that with a diagram exported as an image, where nobody can tell what changed between versions. Notes are built in too, so you can describe why a column exists right next to the column itself, which is the one kind of documentation that actually has a chance of staying up to date.
Then there's the fact that it doesn't care which database you use. You describe the model once and export it for PostgreSQL, MySQL or whatever else you're working with. And because the CLI can go the other way, you can point it at an existing database and get DBML out the other end, which is a surprisingly painless way to finally document that old project nobody has touched in years.
It's worth being honest about what it isn't. DBML is not a replacement for SQL, and it's not a migration tool. It describes the shape of your data, not how to get from the old shape to the new one, and it doesn't cover things like views, triggers or stored procedures. The SQL it generates is a good first draft, but you'll still want to look it over before it goes anywhere near production. Honestly, I think that's fine. It does one job, the job of making a schema easy to see, write and share, and it does it really well.
If you're curious, the best way to get a feel for it is to spend five minutes on dbdiagram.io. Paste in a schema, tweak a relationship, watch the diagram move. That's usually all it takes to see why I like it so much.

From Text to Action: How Your Code Actually Runs

Lawrence — Tue, 11 Aug 2026 19:28:00 +0000

Every time you hit "Run," a hidden pipeline begins transforming the code you wrote into instructions your computer can actually execute. Although programming languages are designed for humans to read, computers only understand machine code, so your program must first be translated. The journey starts with the lexer, which scans your source code, ignores spaces and comments, and groups characters into meaningful pieces called tokens. For example, let x = 5; is broken into a keyword, a variable name, an assignment operator, and a number. These tokens are then passed to the parser, which checks whether they follow the language's grammar. If the syntax is invalid, the parser reports an error; otherwise, it constructs an Abstract Syntax Tree (AST), a hierarchical representation of your program that captures its logical structure rather than its textual form. Instead of seeing x = 5 + 3 as a line of text, the AST represents it as an assignment operation whose value comes from adding two numbers. This AST acts as the universal representation that the execution engine understands. Once the AST has been built, the execution process reaches a critical decision: should the program be interpreted or compiled? An interpreter walks through the AST one instruction at a time, executing operations as it encounters them. This approach provides almost instant startup because there is no build step, making it ideal during development when code changes frequently. However, interpretation comes with a performance cost because the interpreter repeatedly analyzes instructions every time they are executed. If a loop runs a thousand times, the interpreter must repeatedly determine what each operation means before performing it. A compiler, on the other hand, translates the entire AST into machine code before execution begins. This compilation process increases startup time, especially for large projects, but once complete the processor can execute native instructions directly without further analysis, resulting in significantly faster performance. Many modern programming languages, including Java, C#, and JavaScript, combine the advantages of both approaches through Just-In-Time (JIT) compilation. A JIT compiler initially interprets the program to provide fast startup while simultaneously monitoring execution. When it detects sections of code that run frequently, known as "hot spots," it compiles only those portions into optimized machine code during runtime. As a result, the program starts quickly and gradually becomes faster as its most frequently executed code is optimized. Ultimately, the choice between interpretation and compilation reflects a trade-off between startup time and execution speed. Interpreters prioritize rapid execution of newly written code and simpler debugging, while compilers maximize long-term performance by generating efficient machine instructions ahead of time. JIT compilation bridges these two approaches by combining immediate responsiveness with runtime optimization. Regardless of the execution strategy, every program passes through the same essential stage: the creation of the Abstract Syntax Tree, where raw text is transformed into structured logic. From that point onward, the execution engine decides whether to prioritize getting the program running as quickly as possible or executing it as efficiently as possible, making the difference between interpreters, compilers, and JIT compilers fundamentally a question of balancing startup cost against runtime performance.

Ray Tracing

Lawrence — Sun, 14 Jun 2026 15:19:25 +0000

Honestly, the way dedicated hardware and software engineering have teamed up has totally changed the game for developers making worlds look real. Instead of artists spending weeks manually dropping in fake light bulbs to trick your eyes, they can just place one virtual sun in the scene and let ray tracing physics handle the rest. This basically deletes a ton of tedious development time while making sure the lighting always looks right across changing environments. Like, when a character walks from a super bright outdoor courtyard straight into a dark cave, the transition looks completely seamless because the engine recalculates those light paths on the fly.
And honestly, this whole shift goes way beyond video games and movies. Architects use ray tracing to simulate exactly how sunlight enters a building at different times of day, which lets them optimize window placement and energy efficiency before anyone even touches a shovel. Automotive designers rely on it to see how new paint finishes and interior setups look under different weather conditions without needing to build expensive physical prototypes. Even product designers use it to make hyper-realistic marketing images straight from their design files, making it basically impossible to tell the difference between a digital render and an actual photograph.
As tech keeps getting faster, what ray tracing can do is going to get even wilder. Next-gen rendering engines are looking to simulate full spectral rendering, which tracks individual wavelengths of light instead of just mixing standard red, green, and blue values. This means computers will perfectly replicate super complex optics, like the rainbow sheen on an oil slick, light splitting through a crystal prism, or the way light scatters through human skin and deep water. As this keeps evolving, the line between computer graphics and real life is pretty much going to disappear.