DEV Community: Kevin Alemán

What are your most liked agent skills?

Kevin Alemán — Fri, 19 Jun 2026 14:41:59 +0000

An space for sharing your go-to agent skills so everyone can use them.

My list:

Superpowers (planning & implementation)
Caveman (for reducing token usage)
Frontend Design (to help with styling)
Remember (memory)

I have one i created myself called teachme, which uses a bit of thinking to explain topics to you and then it evaluates your understanding.

Gotta Earn 'Em All: The Gym Badges of Agentic Engineering (Part 1)

Kevin Alemán — Wed, 17 Jun 2026 20:13:57 +0000

There's a guy who stands at the entrance to the Indigo Plateau and will not let you through. Level 80 Charizard? Doesn't care. Seven gym badges pinned to your jacket? Come back when it's eight. No matter what you do, he won't let you pass until you meet the prerequisites.

Kid-me thought he was the single most pointless NPC ever programmed. I wanted to go right to the action, not spending 5 hours to get all the badges. Replaying FireRed last month (the GOAT, don't @ me) I finally got what he's for. He isn't guarding the fun part. He's making sure that by the time you face the four people who can actually beat you, you've already survived the eight boring things that made you ready for them.

Which is, more or less, my entire complaint about how we're using agents right now.

Everybody wants to fight the Elite Four on day one. "I'll let the agent build the whole feature." "I'll let it refactor the repo while I grab a coffee." "I'll point Claude Code at the thing and vibe." And sometimes it works! Right up until it doesn't, and you genuinely cannot say why because there were eight gyms between you and that gate and you strolled past every one.

So here's the case, the way a Game Boy made it to me: before you're actually good with agents, there are badges to earn. Not tools to install, things you have to know. Let's go gym by gym.

Badge 1: Boulder Badge: rock before copilot

Brock. Rock type. The first gym. The place where you thought choosing charmander was a bad call (until you trained enough and it learned Metal Claw which helps a little bit).

This is the badge of knowing how to code without the agent holding your hand. The foundations.

I've said this before and I'll keep saying it until they revoke my keyboard: you cannot prompt what you don't know exists. If you don't know your project just changed a function's typings, you won't tell the agent, you won't catch it when it gets it wrong, and you'll merrily ship something that looks right and isn't. The agent didn't fail there. You showed up to the gym with no Pokémon.

You don't need to know everything. You need bedrock. Otherwise every badge after this one is built on sand and you're gonna have a bad time.

Badge 2: Cascade Badge: the agent only knows what you pour in

Water flows, context flows, you see where I'm going. An agent isn't psychic (we'll get to that gym), it knows exactly what's in its context window and nothing else. Not your repo's weird conventions. Not the thing your team decided in Slack last Tuesday. Not the landmine that lives rent-free in one senior dev's brain.

Look at these two and tell me they're getting the same result:

// what most people send
"fix the bug in the user evaluation"

// what you could be doing
"In src/users/evaluate.ts we hardcoded a company name to hit a deadline.
Now we ALSO need to exclude new users from company "bla",
WITHOUT touching how "fancy company" users get evaluated.
Here's the file, here's the test that has to stay green,
here's how we name things."

Same model. The first one is basically throwing a Poké Ball at a wall. The second one is, you know, engineering. Pour the context on purpose and everything downstream gets less cursed.

Don't make your agent drink from a puddle.

There's some cool skills that can make your agent "think" this way, but you have to think that way too, so both agent & you can work together on solving & creating.

Badge 3: Thunder Badge: fast is a trap

Here's what nobody warns you about: agents are fast. Stupid fast. Faster than you. Faster than me. Faster than anything likely. Issues that would take me a week to solve an agent can find a probable cause in minutes. And speed multiplies whatever you give it, your galaxy-brain ideas and your dumbest ones, at the exact same voltage.

I've ranted about this in open-source land: opening a PR now costs basically nothing, but reviewing one still costs a human their actual time and sanity. That gap is a denial-of-service attack wearing a trenchcoat. You tell the agent "do this for every file!!" and now there are 100 changes, some great, some radioactive, and you have to read all 100 because the agent will not tell you which is which. Congrats, you DoS'd yourself.

The badge here is learning to not grab the lightning with both hands. Small tasks. Bounded scope. One thing at a time. A fast wrong answer isn't a head start, it just got to being wrong sooner. :(

Badge 4: Rainbow Badge: it's gardening, not a vending machine

People treat agents like a vending machine: insert prompt, slot opens, finished feature falls out. Nope. It's gardening. You plant a thing, you look at the weird mutant that grew, you prune the cursed branches, you re-prompt, you prune again. Repeat until it's a plant and not a crime scene.

The first output is never the deliverable. It's a sprout. "Good, keep this shape, but the data layer is wrong, redo that part" is the actual loop. The people who look like wizards with agents aren't great prompters, they're patient gardeners who aren't precious about yeeting a bad draft into the sun.

Plant small, prune often, be responsible for what your agent produces cause that's your personal image too.

Halfway to the League

Four badges down. If you actually have these: bedrock, context, scoped speed, and the patience to garden instead of treating the agent like a vending machine, you're already ahead of most people loudly pretending to be good at this.

Learning is a journey. Enjoy it. Don't let agents & AI remove from you the better part of programming: you getting better at it.

Obviously, life is not Pokemon. You could perfectly bypass all of this and go straight into your terminal right now to get a "product". That's acceptable in some cases.

But... where's the fun in that?

You got selected for GSoC 2026, now what?

Kevin Alemán — Mon, 04 May 2026 04:35:06 +0000

So your inbox lit up yesterday with the email. The proposal worked, the interviews worked, the late-night drafts worked. Take a moment, breathe, tell your family, post the screenshot. You earned it 🎉
Now, the actual fun part begins.

GSoC is, at its core, a few months of getting paid to learn from people who have spent years figuring out how to build software that thousands (sometimes millions) of strangers depend on. Think of it as an internship, but instead of a single company, your "office" is the entire open source world, and your "coworkers" are engineers who chose to spend their free time making things better for everyone. That's a rare seat at the table. Don't waste it.

Here are a few things to keep in mind so you make the most of it.

What a mentor looks for from you

They want to mentor, not babysit.

Mentors signed up to guide you, answer the hard questions, and unblock you when the codebase fights back. What they did not sign up for is reading the README on your behalf. The heavy lifting, exploring the codebase, running it locally, breaking it, fixing it, writing code that smells like the rest of the repo, that's on you.

A good rule: if you can find the answer in 30 minutes of digging, dig. If you've dug for two hours and you're more confused than when you started, ping them.

Note 2: at Rocket.Chat, we have an internal meme called :call-the-police: that would fit perfectly above. Sadly, due to GDPR and other international laws, I cannot share above. End of the note.

Honesty is everything.

LLMs are great at giving you an answer. They're not great at giving you the answer for this specific repo, with this specific history, with that one weird workaround that's there because of a bug from 2019 nobody wants to revisit. When you step into that kind of fog, just say so. Mentors respect "I don't get why this is here" way more than a confident wrong guess. That said, don't ask for permission to breathe. There's a middle ground between "I'm stuck on every line" and "I haven't said anything in two weeks", and that's where you want to live.

Let git do some of the talking.

In a lot of open source repos, the git history is the real diary of the project. Match the style: if they squash, you squash; if they write essays in commit messages, you do too. Use commits as a steady drumbeat of progress, and save your mentor's inbox for the moments that actually need a human. Adding a translation? That's a commit. Untangling a nasty bug and finding a creative fix? That's worth a "hey, look at this" message.

What you can ask from your mentor

Treat them like human documentation.

Mentors are walking archives. They know why a function is named weirdly, which refactor everyone is afraid to touch, and that one PR from 2021 that explains everything. Tap into that, but don't drain the well. Try to find the answer yourself first, give it a responsible amount of time, and if you're still spinning, ask. The deadline is fixed, and running in circles is the most expensive thing you can do with your summer.

Ask about the politics the proposal couldn't see.

When you wrote the proposal, you were looking at the project from the outside. Now you're inside, and you'll start spotting things: tech debt, weird coupling, decisions that look wrong until someone explains they're load-bearing. Bring those up. Sometimes the answer will be "yes, let's fix it as part of your work." Other times it'll be "leave it, that rabbit hole eats summers." Both are useful answers, and only your mentor can give them to you.

How to deliver on the proposal you already submitted

The proposal is the map, not the territory.

You can't redraw it: the timeline, the deliverables, the headline goals are pretty much locked. But there's plenty of room inside the lines: code style, data shapes, security choices, edge cases, testing strategy. Talk those out with your mentor early. The earlier the better, because rework in week 10 hurts a lot more than rework in week 2.

Once you've aligned, write a plan.

Break the proposal into weekly chunks, with a rough idea of what "done" looks like for each one. Then, and this is the important part, don't die by the plan. Plans that are too tight have no room to absorb the inevitable: a flu, a flaky test, a rabbit hole, that one dependency that decides to deprecate itself the week you need it. If something can go wrong, it will go wrong. Plan for it.

Murphy's law is an adage or epigram that is typically stated as: "Anything that can go wrong will go wrong."

View on Wikipedia>

When to use AI (and when to put your hands on the keyboard)

Use AI to plan, not to know.

AI is genuinely great for getting your bearings in a new codebase: "what does this module do", "where is X handled", "give me a tour of this folder". The trap is that it'll happily give you confident answers that feel like understanding without actually being understanding. Always review the plan it gives you. Always question its assumptions. At the end of the summer, nobody is evaluating the LLM. They're evaluating you.

Don't let AI eat your learning.

This is the part I want you to take most seriously. GSoC is one of the safest spaces you'll ever get to make mistakes: you have a mentor, a stipend, and explicit permission to be a beginner. If you outsource the thinking to an LLM, you're trading the most valuable thing about the program for some saved keystrokes. Especially when it comes to understanding issues: sit with the problem first. Read the code. Form your own theory. Then maybe ask the AI for a second opinion. AI already "knows" a lot of stuff. The whole point of the summer is: what do you know?

Balance check: we don't want you to feel we (or I) hate AI. AI is really cool and I'm very happy on using it. But as prof. Oak liked to say: "There's a place and time for everything". AI is cool, but the human using it is cooler.

Maintainers can smell it.

I've reviewed enough PRs to tell you this isn't a cute claim: it's true. Code that's 100% AI and 0% human reads differently. The variable names are too generic, the comments explain things nobody would explain, the solution is technically correct but doesn't fit the shape of the codebase, the PR title and/or the code make no sense. Mentors will spot it. And we, the mentors, want you to learn, that's the whole point of GSoC. We want more maintainers for the future. You can be one of them if you use this opportunity.

Wrapping up

You'll quickly realize getting selected was the easiest part. This summer is the real thing. Drive your own work, ask the smart questions, ship the small stuff, keep AI as a tool and not as a crutch and you'll come out the other side a much better engineer than the one who opened that email yesterday.

See you at the final eval 👋

Got featured :noice:

Kevin Alemán — Tue, 10 Mar 2026 16:45:59 +0000

Jess Lee for The DEV Team

Mar 10

🙌🏽

Kevin Alemán — Sun, 08 Mar 2026 18:51:54 +0000

Kevin Alemán

Mar 4

In the AI Era, Code Is Cheap. Reputation Isn’t.

#ai #opensource #programming #software

6 min read

In the AI Era, Code Is Cheap. Reputation Isn’t.

Kevin Alemán — Wed, 04 Mar 2026 21:01:29 +0000

In the era of AI it's easier than ever to be an Open Source contributor!

But, at the same time, and quite paradoxically, it's harder than ever.

Why? Because it's now mechanically easier, but reputationally harder

Previously, you competed against other incredibly smart volunteers, or maybe against employed developers that contributed their expertise and free time to open source, or against newcomers. Now, you compete against all of that and an army of AI agents generating pull requests, issues, refactors and vulnerability reports faster than what any human can do.

It's pretty tempting. Using an LLM can reduce significantly the cognitive work you have to do to understand a codebase, and even to produce a valuable change request. Things that were previously "very hard" to do are now a few prompts away, and that lowered the entry barrier for contributions, which is great! But also created a massive increase in volume, which is flooding repositories.

What's the problem?
Maintainer capacity did not increase
Review cost did not decrease

These two truths have already led maintainer to resort to drastic measures, like what happened with curl:

Death by a thousand slops | daniel.haxx.se

daniel.haxx.se

So, how do you become a valuable Open Source contributor in the era of infinite code generation? Here are a few tips learned from dealing with a large volume of contributions:

1. Think. Then think again

AI can produce great code, but it can also produce the worst code ever seen by the humanity. This depends a lot on:

The prompt that you use
The quality of the LLM
The context being shared

And the most important one:

Your own coding abilities.

Why do you need to know how to code before using LLMs to contribute to open source?

Well, because an LLM cannot know everything.
For example, we had a PR that attempted to change this:

        } catch (error) {
            console.error('Some error:', error);
        }

After

        } catch (error) {
            logger.error('Some error:', error);
        }

You would say: that is a valid change, we want to use logger instead of console! What's the problem?

The problem was that the LLM didn't know (and didn't check, cause it wasn't asked to) that we recently changed the typings on our logger instances, rendering the change invalid.

What a valid change would have looked like:

        } catch (err) {
            logger.error({ msg: 'Some error', err });
        }

But, the LLM didn't know this, and it would have required quite some context for it to know. Good LLMs (Claude, Codex, etc) would have caught, but others would not, unless you asked them. How would you ask something that you didn't know? There's where your coding abilities enter into play.

Here's the key point: You cannot prompt what you don't know exists

Someone that wants to be a contributor doesn't trust blindly on what the LLM produces. Knows how to use the tooling (typecheck, in this case) to catch those issues, reads the code to understand current conventions, caveats, etc.
For this programmers, LLMs become a powerful tool, cause it helps you with the mechanical task of coding and gives you enough time to think.

This also protects your reputation. If maintainers see a pattern of low-signal PRs from you, they’ll eventually stop reviewing them. Or worse.

LLMs make contribution faster, but they don’t replace your brain unless you let them.

2. Respect volume. Review is not free.

You are happy. We're also happy that you want to contribute to open source. It's a noble endeavor and it's something that helps the repository to be safer & you to be better. It's a win-win!

But, maintainers have:

Limited capacity.
Limited time.
Limited patience.

We understand, you are happy you created your new PR, and we understand the joy in you of doing that. We've all being there. You want, for sure, your PR to be merged so you can say with honor: "I contributed to X!"

But, be reasonable:

The cost of opening a PR is now near zero.
The cost of reviewing it is not.

This asymmetry is the real tension of the AI era.

If you:

comment “please review” repeatedly,
ping maintainers aggressively,
demand merging timelines,

You’re increasing the cognitive cost of your contribution. Even if your PR is valid.

And here’s the harsh truth:

Maintainers are human.

If interacting with you feels expensive, they may subconsciously deprioritize your work. That means fewer reviews, fewer merges, fewer release notes mentions.

This is specially important when you use LLMs or Agents as they are fast, way faster than humans, so you could end up doing 100 PRs that you think are valid, and maybe they are! But if the maintainers don't have the capacity to review them all, they just won't.

That's the definition of a DoS (Denial of Service): you send more requests than what the server (maintainers) can process.

3. Quality that doesn't cut corners (pls don't sue me Wendy's)

Maintainer capacity is low. We closed around 700 issues (stale, invalid, fixed) in the past month, but at the same time, we received 300 new issues. Some of those issues were valid, some of them were not. The problem is we don't know beforehand, we have to check them all. You cannot trust an LLM to confirm if something is slop... cause the check may be slop too!

Related link, curl fighting against AI slop vulnerability reports:

HackerOne Curl report

As you see, maintainers won't be happy if you waste their time, cause they have stuff to do. The link above, as well as this beautiful list

have something in common: they look legit, until they don't. However, for realising something is slop you have to check manually, and that is time/effort wasted.

So you have to be human, respect the times maintainers have and respect their work. How you do that? Helping the maintainers reduce the cost of reviewing your code:

Before submitting:

Did you reproduce the issue yourself?
Did you run CI locally?
Did you include screenshots for UI changes?
Did you provide benchmarks for performance claims?
Did you include a PoC for security reports?
Did you check if a feature request already exists?

If you claim a performance improvement, show numbers.
If you fix a bug, explain the root cause.
If you propose a feature, ask first.

High quality contributions get reviewed faster.
Low signal contributions accumulate.

In the AI era, reputation compounds. If maintainers can trust you, your PRs will be reviewed faster, and you will feel happier. Win-win!

4. Bundle trivial changes.

Typos happen. Smol mistakes happen. For example

Before:

        if (!sub) {
            throw new Error('subsciption not found');
        }

After

        if (!sub) {
            throw new Error('subscription not found');
        }

Do you spot the bug? Yep, a missing r on subscription. The contribution is valid, yes, we want to write correct words in english.

Does it deserve a PR? Not by itself, maybe if you combine a few more. Think if you find 10 of those misspellings. What's easier for maintainers? 1 PR with 10 changes or 10 PRs with 1 change? Hehe.

If you were the maintainer, what would you prefer?

Every PR has overhead: CI runs, notifications, review time, merge time, mental context switch, etc. Reduce the overhead by batching trivial work.

AI can find an enormous list of fixes like this in a codebase, and if you use an agent like Claude or Clawd you can tell "Hey for each issue create a PR" and then become the most hated contributor on the project :(

Don't do that. Please. Be mindful. Be human.

LLMs are fun, but human work is better.

We're on the AI era, we cannot fight AIs anymore, they're here to stay. What we can fight is how we use them.

For GSoC for example, we value human contributions. That's the point of the program: more humans converting to open source contributors!

We need new generations of maintainers, of smart people that will use LLMs wisely. You can do amazing stuff with them if you use them properly, but nothing will replace your ability to do amazing stuff as a human. You have to remember that.

It's easier to contribute, but harder to stand out from the crowd.
Reputation matters.
Trust is earned.
You build it by doing good work.

As a final note, this is pretty much personal experience. Some projects may have different rules. Some may like to receive 1000 PRs a day (?) idk.

But, the main point is: AI is not human, but maintainers and contributors are. So remember that.

Welcome to Open Source!

If u want to read more:

AI is destroying Open Source, and it's not even good yet - Jeff Geerling

Over the weekend Ars Technica retracted an article because the AI a writer used hallucinated quotes from an open source library maintainer. The irony here is the maintainer in question, Scott Shambaugh, was harassed by someone's AI agent over not merging its AI slop code. It's likely the bot was running through someone's local 'agentic AI' instance (likely using OpenClaw). The guy who built OpenClaw was just hired by OpenAI to "work on bringing agents to everyone." You'll have to forgive me if I'm not enthusastic about that.

jeffgeerling.com

You're doing great, and you need to hear that :)

Kevin Alemán — Wed, 15 Sep 2021 16:09:03 +0000

I'm not the kind of person that likes to be "thanked" for something. I like to do the things, and that's it. And later I realized it was not only me who felt this way. But, is receiving recognition something reserved for super special situations?

Everyone needs to be "praised" for doing a great work

Being praised releases dopamine, that's why you feel happy when someone recognizes your work and says that it's good. Everyone likes that feeling of "doing something amazing" by receiving a simple "thanks for helping me". But, it doesn't stop there.

Your motivation is also increased. It's important to note that everyone has a different set of motivators, so what may work for someone probably won't have the same effect for others. But there are some common motivators in a workplace, like the compensation. Receiving a considerable wage and a good compensation plan on your company may motivate you to work better. Same as having a clean workstation, or having a good team composed of capable people. Recognition is also a key motivator, that means, surprisingly, that people feel good when they're recognized :)

However, as any other dopamine-releaser, the effect of recognition is transient, and, it may decrese the effect over time when it's done too much. So, recognition should be given timely.

Timely recognition

So, how do we achieve a recognition scheme that's not sporadic but is not rare at the same time? Balance, as always, is the key.

This is more an HR topic, probably at your company there's a lot of people trying to fix this same issue, because recognition is not as easy as it may look. Fairness plays a really important role. What if another employee who does the same thing I do receives recognition every week, but I receive it every year? Then, recognition becomes a problem and a demotivator, so it's important to watch out how recognition will be conducted.

But, let's return to the frequency. From this BI Article, a weekly recognition scheme is good. Probably you don't need it to be too frequent. Think for example, on sprints. If your sprints are 2 weeks long, why not dedicating some time at the end to thank your colleagues for their work?

The same article says that this type of recognition helps the employee to be engaged, and trying to get that recognition again, because people like that. Try to avoid recognizing your employees just with the normal performance review cycle, because that may be too late.

Again, if your colleague did something really good for you or the team, don't wait to say thanks. Recognition has a "shelf life", that means, it can expire if not used at the right moment!

So, key points for timely recognition:

Do it before it expires :)
Don't wait to normal performance review cycles to recognize people
Be fair

How to create a recognition culture?

Make it easy
Your team should feel that it's easy to give recognition. If people find a lot of requirements or an extremely formal process for doing so, they won't do it.
Be specific
Saying "thanks" is good, but it's even better when you know the reason for that. So saying "thanks for helping me with the last presentation" would be much more valuable than just saying thanks, because that means you're recognizing a specific effort, and not just saying a canned response.
Connect the dots :)
Relate the recognition with your company's values. This makes easier for your team to know how they're contributing to the company's objectives and culture, and that creates a strong culture :)
Make it for everyone
Avoid having only managers giving recognition. Foster p2p recognition, since that'll create bounds between your team.

(Key points taken from this article

So, as conclusion, thanks for what you're doing to improve the community :) and thanks for sharing your knowledge with the rest of the people using this platform.

Now, go there and recognize people for what they're doing :)

The beauty of Streams in Node

Kevin Alemán — Fri, 02 Oct 2020 21:06:17 +0000

Probably you have heard of them, probably you don't. But they have been around for a while. We're talking about streams, an interesting and often ignored functionality of Node.JS.

What are streams?

To make things easier, we will define a stream as a sequence of data that flows freely. Think of streams like rivers. Rivers flow from one point to another in a constant way. The receiver doesn't know when the river will stop flowing but it's always there for receiving more water.

In Node, streams are very similar. They are a constant sequence of data. They flow from one point (emitter) to another (receiver).

The receiver can decide if it wants to receive data or not. Also it decides what to do with the data received. It can ignore the data, pipe it to another receiver, parse it before receiving...

Why are streams useful?

This is a really good question. If you have lived without streams your whole life, you will think that you don't need them. And, depending on your use case, this could be true.

But the reality is that we need to use streams for some operations that otherwise will kill us. Let's put an example

Dealing with files

Let's say we want to create a compressed copy of a file on our disk with a Node application. Usually, we will end up with something like this:

fs.readFile(file, (err, buffer) => {
  zlib.gzip(buffer, (err, buffer) => {
    fs.writeFile(file + '.gz', buffer, err => {
      console.log('Done!!');
    });
  });
});

Imports removed for brevity

Here, we're doing 4 things:

We're reading the entire file and saving the data to a variable called buffer
We're using the zlib.gzip to compress the file into a gzip. We're passing the buffer to the function call. This will return a new compressed buffer
We write the compressed buffer to a new location
A console.log indicating that the operation finished

Well, this works. What's the problem with this approach? You may be wondering. Well, look again at the first 2 steps. In this approach, we're reading the whole file before starting to process it. Additionally, we're storing the contents of that file in memory. This is not a problem if the file size is in MB. But, if the file size is in the order of GB? Hundreds of GB? Will your computer have all that RAM available to hold the file in it? Probably no.

So, this approach, even when enough for more simple tasks, represents a problem when we're looking for performance and scalability, or simply we want to support larger files.

The problem can be solved by using streams. Let's see how:

fs.createReadStream(file)
  .pipe(zlib.createGzip())
  .pipe(fs.createWriteStream(file + '.gz'))
  .on('finish', () => console.log('wooh!'));

We're doing some things different here:

We're creating a read stream. This will return us chunks of the file until it reaches the end.
We're piping the chunks to zlib for compression. What's important here is that we are not waiting for the whole file to be read before starting the compression.
We're creating a write stream in which we're passing chunks of data so Node can write them to the file.
After all, we listen for the finish event, which will be triggered when there's nothing more to do.

There's a vast set of details & quirks & functions related to streams which will be covered in other blog posts.

Hope you liked it!

Building a new feature: talks preview

Kevin Alemán — Fri, 11 Sep 2020 06:59:14 +0000

I'm a backend developer, so most of the time I'm doing backend things. I feel stressed most of the time when I need to do something at the front.

Then, I started to build my own personal site. And it was great! It's a blog site located temporarily at Netlify where you can contact me, read what I wrote, share my content with a suggested tweet, and now you can see the talks I've given in my career.

The talks are mostly about basic topics, one of them is in progress yet, but I wanted to showcase that I made them. And this was when the trouble begins

How?

The first thing was to define what I wanted: I wanted to showcase my presentations. This was easy (in my mind), but, it wasn't easy in real life.

To give you more context, I store all my presentations in Google Drive, so I can work on them wherever I go. This makes things easier for working on them, but a little bit hard if you want to show them offline.

Why? Because first, you have to download the file. This is a no-brain task with a UI, just right-click and download. GG. The task gets more complex when you want your code to perform that process. So I walked a lonely road, the only one that I have ever known: looking for someone who tried the same and succeeds.

I found multiple Gatsby plugins by just typing drive or google drive into the search box. I tried every single one, with the hope of finding what I wanted. Here's a list of the highlighted ones if you are trying to do something similar:

gatsby-source-google-docs

The problem: the use case I had in mind was very different from what the library did

gatsby-plugin-drive

The problem: it only allowed me to download DOC files (not presentations, which was what I wanted)

gatsby-source-drive

The problem: it didn't work. Maybe I misconfigured something or so.

gatsby-plugin-docs-sheets

The problem: it only allowed me to download Sheets. I'm pretty sure this was based on gatsby-plugin-drive)

So, since no plugin was able to fulfill my needs, I had to make a difficult decision:

Give up on my feature
Create my own plugin

I took the second, and this plugin was the result: Gatsby-plugin-googledrive

The entire plugin was based on a single idea: given a Google Drive's folderID, download all files from the folder, and traverse the subfolders recursively to create the same structure on your selected destination. And download the files for each folder.

The technical details can be found at the GitHub of the project and, it's open-source, so if you want to build something around it feel free to do so.

How? Part 2

After creating my plugin, I "plugged" it and the download started. I finally had the files on my local, and this was one step closer to my goal.

I had the PDFs on my local, now, I wanted to do 3 things:

Get the URL from the PDF in my filesystem (and application!)
Get the first page of the PDF (the "cover page")
Convert that page to an image, and show it on a nice grid

Soo, I needed 3 things:

One way to get the PDF from my filesystem
One way to read the PDF
One way to convert the read PDF into images

For the first item, since I'm using Gatsby, I used the gatsby-source-filesystem to read my folder and get the actual asset URL pointing to my file. It was really easy, just added this to my gatsby-config.js file:

    {
      resolve: "gatsby-source-filesystem",
      options: {
        name: "talks",
        path: "${__dirname}/src/talks/",
      },
    }

And that's it! Then, to query my filesystem and get the nodes with data, some graphql was needed:

  query {
    allFile (filter: {sourceInstanceName: { eq: "talks" } }) {
      edges {
        node {
          name
          publicURL
        }
      }
    }
  }

That query will do 2 things:

Get all the files under the path of the instance name called talks (which is the name property you pass to the plugin definition)
For each node aka file, get its name and publicURL (which is the URL that the asset will have after the building)

For the second item, I had to do some research. After some looking, I finally found PDF.JS which is like the standard for managing PDFs in JavaScript. It was written by Mozilla and has a ton of useful functions. I just used the basic API to get my feature working in a few LoC.

PDFJS.getDocument(talk.publicURL).promise.then((pdf) => {
      pdf.getPage(1).then((page) => {
          // some code goes here
      })
})

The introduction to the library in its GitHub page was simple, maybe too small for my taste, but it worked. With this, the only thing left was to find a way to convert the PDF page's data into an actual image.

I found a pretty nice approach to accomplish that. It worked like this:

Read the PDF page
Scale the page's width and height (by using the viewport of the page)
Create a <canvas> element
Set the canvas context to 2d (since we'll draw an image)
Set the scaled page as the new data context for the canvas

The full code was linked in this StackOverflow's answer which even had an example of how it worked. Nice.

With all of that in place, the final result:

Hope you liked the article, feel free to also visit this post on my own website

Algos in real life: binary search

Kevin Alemán — Fri, 04 Sep 2020 20:14:12 +0000

You probably know about algorithms. You probably don't. So here's a basic definition: an algorithm is a chain of steps for moving from A to B.

If you want to make a sandwich, you probably have an algorithm for that. Mine is:

Get the ingredients
Separate bread and put it on a plate
Put some dressing on both halves
Put lettuce, tomatoes, pickles (if any) on one half
Put ham, cheese, ham again on one half
Add extra things (this is, probably whatever I can find that fits my sandwich)
Put the empty half over the other ingredients
Eat

Whatever your process is, the point is you use an algorithm for that.

Algos are really useful, in programming and real life. Here, I'll show you an example of how I used one of those algos to make my life (and work) easier.

The task

Suppose that you were assigned to solve an issue at work. Depending on the kind of issue this may be easy peasy lemon squeezy or you can end stressed depressed lemon zest.
The issue in this example is a simple one: a function was working at some time in the past, but now it's not. Easy.

You fix the function, upload your changes, and create a merge request. Everything fine at this point.

Then, someone from above asks the hard question: "Hey, this worked in the past, could you tell me when it stopped working?". If like mine, your project has a ton of commits, then you'll have fun, more if your commit history looks like this:

The solution

You have 3 options here:

Cry in a corner
Traverse all your commits until you find one where it was working
Do something good with the knowledge you have

Ok, after doing the first we can start thinking on a real solution. And here's where algorithms come handy. Let's remember one of them!

The binary search algo, or the principle of divide and conquer.

You may remember that algorithm from a class, a course, some reading, or any other place. In case you haven't, I'll leave a brief explanation here:

The main idea of this algorithm is to, given a sorted list and a value to find as inputs, traverse the list to find the value you're looking for.

The main point of difference between this and other search algos is how the list is traversed.

In traditional searching, you go from the start until the end (in the worst case) to find what you're looking for. If you reach the end and you haven't found the value, then it's not there. Something like this:

In a binary search, however, you "divide" the list in halves, then compare the middle value with what you're looking for. If the value is greater, then you repeat the process in the left half, otherwise you use the right half. You repeat this until you cannot divide your input list anymore. Something like this:

To use a binary search, you just have to follow some rules:

Your list must be sorted
Your list must be sorted
Your list must be sorted

Ok. You got this, the list must be sorted. Let's continue with the solution!

The solution (part 2)

Since our commit history is sorted (by the date of the commit) we can perform a binary search on the commit history!

I selected some old commit (like 20 days before) as my start point and my current commit as the last item.
I, then, selected the middle one (this was made visually) and checkouted to that commit.

Was functionality working? Yes? Select a more recent one! Else, use an older one.

You know how the story ends. I was able to verify the whole commit history in like 20 minutes, when it may have taken 2 hours due to the number of commits in the pool.

Moral: if you know how to do something fast, do it! And, algos are also useful in real life!

Hope you liked this history, and let me know if it helped you! Thanks for reading 🎉

Developing JS/TS with VIM

Kevin Alemán — Thu, 18 Jun 2020 06:48:58 +0000

In the beginning, there were editors. And VIM was an editor. And VIM was the editor.

I started to code 3 years ago. When I started to code, I remember having one coworker that was using Emacs. He just stared at its screen without using the mouse, and all he was doing was using the keyboard to do what he needed. He tried to convince me to use Emacs as well, but something didn't feel so good when using it.

I, then, started to use VSCode. The good VSCode. I don't have anything to say against him. VSCode is an excellent editor. The only thing that stressed me out was its insane memory usage! After all, it's built in the top of Chromium, so it will use the RAM accordingly. VSCode is a perfect editor for almost anything you want to do. Do you want to write Java? There's a plugin. Do you want to test your API? There's a plugin. Do you want to manage your database? There. Is. A. Plugin. It's not an IDE because they haven't given the title to it!

Even when that rich ecosystem is something beautiful by itself, it can led to some issues. The memory usage may go insane as you install more extensions. And disabling them based on the workspace (which you have to configure manually) instead of filetype stressed me more.

So, there was a time, when I was working in a project that used a lot of docker containers, they used a lot of RAM by themselves, and I was using VSCode too. The RAM cake was starting to finish. Also, I had Chrome and another applications that I use to do my work (like Slack, which is also on top of Chromium) trying to get a piece of cake too... My computer didn't like that, so it crashed. This happened consistently for one month. I tried to change browser, to use Slack in my phone, to do some kind of black magic to get the most of my PC, even I tried to download more RAM (I really expected this one to work... :( ). But nothing happened.

Then, the illumination came to me.

I took a course, and one of the instructors was using VIM, but it was like an IDE. It was perfect. He moved so quickly between tabs (buffers) and commands were intuitive. The color scheme was great, the speed was really impressive. He had autocompletion and listing... everything was perfect.

Motivated by this, I went to my laptop and installed VIM. But...

IT WAS NOT LIKE THE VIDEO. WHY? I didn't have the autocomplete, neither the status bar nor the file explorer... it was just an empty console. Like Emacs was. And also I wasn't able to get out of it.

I realized that Vim was not pretty out-of-the-box. You have to work on it before using it to write code. So I spent a few days reading VIM tutorials and contents. I looked for online resources, and found these:

After finishing 2 of those (obviously the first 2...) I was ready to start to use VIM.

The shorcuts

This is a list of the basic shortcuts I learnt before using VIM. These ones allowed me to at least know how to use it.

To exit vim: :q
To enter in edit mode: i (yeah, just type i and you will get into edit mode)
To exit edit mode (and all other modes): esc
To "save a file": :w
To close without "saving": :q!
To split "tabs" vertically: Ctrl + wv
To split "tabs" horizontally: Ctrl + ws
To change between "tabs": Ctrl + ww

The plugins

First of all, like every person looking for knowledge, I typed How to add plugins to vim in Google. I followed some links and one of them took me to Pathogen, which is a package manager that uses Git (just Git) to get the plugins. I also read about VimPlug, but Pathogen was my choice.

Why? Well, I liked the way it should be enabled:

execute pathogen#infect()
syntax on
filetype plugin indent on

Do you see? Pathogen "infects" VIM. Isn't it nice? Well, I probably lol'ed so hard when reading that, more than I should. That convinced me to use it instead of VimPlug.

Later, I discovered VIM 8 had native plugin support...

The plugin list

Now that I had a plugin manager, I needed plugins. Where did I find them? I used Vim Awesome to get a list of most used plugins and filter the ones that were related to JS/TS/Go. Then, I installed them. Here's the list of the modules I have downloaded for my current development:

(Images taken from Vimawesome)

The NERDTree (to interact with the filesystem)
Vim Airline (to get nice look and feel)
Vim Fugitive (this plugin is so awesome that it should be illegal)
Vim Polyglot (for really good syntax highlight)
ALE (An asynchronous linting engine. This is very useful to configure ESLint and Prettier in Vim)
COC.vim (the ultimate code completion plugin)

These aren't all the plugins I use. I just wrote there the most important ones. The ones without its help I wouldn't be able to write code in VIM.

The final product, using the plugins and one theme that I found (it's called onehalfdark) was this:

Hope you liked my intro to the Vim world, and maybe this motivates you to start getting into Vim!

Fuzzy Searching with PostgreSQL

Kevin Alemán — Mon, 11 May 2020 17:12:11 +0000

What's fuzzy search?

A fuzzy search is a type of search where the items are returned even when they are not an exact match. A fuzzy search is performed by a fuzzy algorithm that evaluates the likeliness between the search query and the values, even when the search query is misspelled or the order of the words changed.

For example, let's assume that we're using Google to find information about washin machines. As you can see, the word washing is misspelled. But even when Google knows that it'll return results that are somewhat similar to what you typed. Sometimes it even tries to correct you!

Well, that's a fuzzy search. Returning elements that are just similar one to another.

How's searching occasionally implemented?

Let's take a typical requirement: allow a user to search other users by its name. To accomplish that, you may end up building a query like this one:

SELECT * FROM users WHERE full_name ilike '%query_param%';

Assuming you have a user named Jonh Doe in your database, looking for Jonh, JonH, jOnh, jonh doe, Jonh Doe and so on will return the value you're looking for. But, what if the user types Doe Jonh?

Well, for sure your app won't crash with that input. But I'm pretty sure it won't return anything! Why? Because the order of the words is different than what's stored on the database, and ilike won't do that rearrange of the words to match. One way to overcome this is to query also for the words in a different order, but that's not elegant.

Apart from that, what happens if now the user (yes, always the user, ugh) types john doe? There are some ways to handle this with ilikes but, why doing that amount of work when you can let PostgreSQL do that for you?

Let's introduce pg_trgm. A PostgreSQL extension based on something called a trigram that will be very useful for this! But, first of all, what's a trigram?

PostgreSQL trigrams. What are they?

The basic definition of trigram is: "A group of 3 consecutive written units, such as words, letters, etc". The pg_trgm extension allows us to divide a word in such.

How does a trigram look like?

To see how a trigram look like, let's enable the PostgreSQL extension first!

CREATE EXTENSION pg_trgm;

After that, run:

postgres=# select show_trgm('abcdefghijk');
                        show_trgm                        
---------------------------------------------------------
 {"  a"," ab",abc,bcd,cde,def,efg,fgh,ghi,hij,ijk,"jk "}
(1 row)

As you see, it'll divide the word into groups of 3 characters. Why there are spaces in the first and last trigrams? Well, that's because PostgreSQL assumes that every word to be converted into a trigram has 2 spaces before and one space after. Why? This allows PostgreSQL to create trigrams for words with less than 3 characters (we, for example). Also, this makes the similarity to take into account the first and last characters, which otherwise would have less weight when the trigrams are generated.

How to use them to find similar words?

If we select the trigrams for 2 words, we should be able to find how similar those strings are. How? By counting the number of trigrams they share!

postgres=# select show_trgm('Friend');
              show_trgm              
-------------------------------------
 {"  f"," fr",end,fri,ien,"nd ",rie}
(1 row)

postgres=# select show_trgm('Friendship');
                      show_trgm                      
-----------------------------------------------------
 {"  f"," fr",dsh,end,fri,hip,ien,"ip ",nds,rie,shi}11
(1 row)

How we find those similar trigrams between the 2 sets? Correct, an intersection!

postgres=# select a                                                 
from (select unnest(show_trgm('friends')) as a) as a
intersect select b
from ( select unnest(show_trgm('friendship')) as b) as a;
  a  
-----
 rie
 fri
  fr
   f
 end
 ien
 nds
(7 rows)

As you can see, there are 7 trigrams common between the 2 sets. Now, how do we know how similar they are? We can do that by calculating a similarity coefficient between the 2 words. How?

word_similarity = common_trigrams / first_word_total_trigrams

Why we use the first word? Well, because we're comparing the first against the second word. We don't care about the excedent trigrams from the second word because we know they won't correlate to the first one.

Now, let's apply the formula. We have 7.00 common trigrams, and we have 8.00 total trigrams in the first word. Let's use PostgreSQL to determine the coefficient:

postgres=# select 7.00 / 8.00;
        ?column?        
------------------------
 0.87500000000000000000
(1 row)

Here, we use decimals because otherwise, PostgreSQL will ignore the decimal part of the operation, thus returning us 0.

Now, we know that our words have a similarity of 0.875. That means they are very similar! But, having to do all of this manually may take time... there should be a better way.

Well, there's a better way! Alongside the trigram extension, we enabled a set of functions that came in the same packages. For example, the whole process we've done for calculating the similarity is abstracted away into a single function: word_similarity. By using the function, we can get all of this process into a single line:

postgres=# select word_similarity('friends', 'friendship');
 word_similarity 
-----------------
           0.875
(1 row)

And even better, there's a set of useful operators that are built into the same package we're using! For example, we may let PostgreSQL decide if two words are similar or not by using the <% operator:

postgres=# select 'friends' <% 'friendship';
 ?column? 
----------
 t
(1 row)

That operator returns if 2 words are similar or not by using a word_similarity_threshold, which we can query too:

postgres=# select show_limit();
 show_limit 
------------
        0.3
(1 row)

Note that show_limit() function is deprecated, but still works.

That limit is, the minimum coefficient a pair of words can have before marking them as different. You can modify that threshold using the set_limit() function and provide new value, but for most use cases, the default one should work!

Using trigrams, we can also query for the "distance" between 2 words, which is calculated by taking the similarity of the words from 1.

distance = 1 - similarity(word_1, word_2);

With the <-> operator. The lower the number the more similar (or less distance) they have.

postgres=# select 'friends' <-> 'friendship';
 ?column? 
----------
 0.416667
(1 row)

We can use this operator to build something like Google's did you mean functionality, which is probably done with n-grams.

Building a `Did you mean` engine

First, let's create a table and populate it with data. For this example, I'll be using the departments of my country, El Salvador.

postgres=# create table t_departments(name text);
CREATE TABLE

And now, some data:

postgres=# insert into t_departments(name) 
values ('San Salvador'), ('Chalatenango'), ('Ahuachapan'), ('Cabanas'), ('Sonsonate'), ('La Libertad'), ('Santa Ana'), ('La Union'), ('Cuscatlan'), ('San Vicente'), ('La Paz'), ('Usulutan'), ('Morazan'), ('San Miguel');
INSERT 0 14

postgres=# select * from t_departments;
     name     
--------------
 San Salvador
 Chalatenango
 Ahuachapan
 Cabanas
 Sonsonate
 La Libertad
 Santa Ana
 La Union
 Cuscatlan
 San Vicente
 La Paz
 Usulutan
 Morazan
 San Miguel
(14 rows)

Now, what happens if the user is looking for San Salvador but it misspells it and write sn salvador? Our system should recommend the user to write it properly! How? Let's see:

postgres=# select * from t_departments order by 'sn salvador' <-> name limit 3;
     name     
--------------
 San Salvador
 Santa Ana
 San Miguel
(3 rows)

And 🎉. By returning the first result, we can tell the user that we know what he was trying to write, and still, return results related to its search, as Google does!

Solving our initial problem

Well, our initial problem was the user, right? Jk, our initial problem was to handle misspellings when users type a name, but they still want a result.
It's now trivial to do this with our new knowledge, by querying either the word similarity or the distance between the words.

postgres=# select * from ( select unnest(array['jonh doe', 'jane doe', 'mark twain', 'some user', 'a person', 'tommy shelby']) as names) as a order by 'doe jonh' <-> a.names limit 3;
   names    
------------
 jonh doe
 jane doe
 mark twain
(3 rows)

Ignore Mark Twain...

I hope you liked the article, and if you are curious and want to delve more, you can read the whole documentation for trigrams and all the operators you can. In my next blog post, I'll share how to index this kind of data so the queries are faster!

DEV Community: Kevin Alemán

What are your most liked agent skills?

Gotta Earn 'Em All: The Gym Badges of Agentic Engineering (Part 1)

Badge 1: Boulder Badge: rock before copilot

Badge 2: Cascade Badge: the agent only knows what you pour in

Badge 3: Thunder Badge: fast is a trap

Badge 4: Rainbow Badge: it's gardening, not a vending machine

Halfway to the League

You got selected for GSoC 2026, now what?

What a mentor looks for from you

They want to mentor, not babysit.

Honesty is everything.

Let git do some of the talking.

What you can ask from your mentor

Treat them like human documentation.

Ask about the politics the proposal couldn't see.

How to deliver on the proposal you already submitted

The proposal is the map, not the territory.

Once you've aligned, write a plan.

When to use AI (and when to put your hands on the keyboard)

Use AI to plan, not to know.

Don't let AI eat your learning.

Maintainers can smell it.

Wrapping up

Got featured :noice:

Top 7 Featured DEV Posts of the Week

🙌🏽

In the AI Era, Code Is Cheap. Reputation Isn’t.

In the AI Era, Code Is Cheap. Reputation Isn’t.

Death by a thousand slops | daniel.haxx.se

1. Think. Then think again

2. Respect volume. Review is not free.

3. Quality that doesn't cut corners (pls don't sue me Wendy's)

4. Bundle trivial changes.

LLMs are fun, but human work is better.

AI is destroying Open Source, and it's not even good yet - Jeff Geerling

You're doing great, and you need to hear that :)

Everyone needs to be "praised" for doing a great work

Timely recognition

How to create a recognition culture?

The beauty of Streams in Node

What are streams?

Why are streams useful?

Dealing with files

Building a new feature: talks preview

How?

How? Part 2

Algos in real life: binary search

The task

The solution

The binary search algo, or the principle of divide and conquer.

The solution (part 2)

Developing JS/TS with VIM

The shorcuts

The plugins

The plugin list

Fuzzy Searching with PostgreSQL

What's fuzzy search?

How's searching occasionally implemented?

PostgreSQL trigrams. What are they?

How does a trigram look like?

How to use them to find similar words?

Building a Did you mean engine

Solving our initial problem

Building a `Did you mean` engine