DEV Community: Ant The Developer

Agentic AI Glossary Cheatsheet

Ant The Developer — Thu, 15 Jan 2026 23:09:00 +0000

Quick reference guide for Claude Code and agentic AI terminology. I have a longer ai glossary for claude code on my personal blog.

📃 Quick Reference

Skill

What: Auto-invoking function registered with your tool
Location: ./claude/skills/[skill-name]/SKILL.md
Run: /my-skill-name (also, runs automatically)

Example:

---
name: build-component
description: Build a React component with tests and stories
---

Instructions for building the component...

Subagent

What: Specialized agent controlled by your main agent
Location: ./claude/agents/[agent-name]/
Create: /agents command in Claude Code
Run: runs automatically

---
name: documentation-creator
description: Creates easy-to-read documentation
---

You are a documentation writer...

Command (Deprecated)

What: Slash command shortcuts (use Skills instead)
Location: .claude/commands/review.md
Run: /review

🔑 Term Definitions

Skill

A special file (SKILL.md) that describes an action Claude Code can take. Think of it as an auto-invoking function.

Key points:

Auto-loads based on name and description
Entry point is always SKILL.md
Can include templates, scripts, and examples
Auto-runs without explicit invocation

Use for: Repeated tasks, component generation, documentation, custom scripts

Subagent

Another instance of an agent controlled by a higher-up agent. Agent = LLM + Tools.

Key points:

Agents can have multiple subagents
Built-in subagents for exploration, planning, multi-step operations
Autonomous workers with their own context/prompt
Respond to the controlling agent

Use for: Code exploration, planning implementations, multi-step workflows, custom automation

Command (Deprecated - Use Skills)

Slash commands that trigger predefined prompts or system functions.

Key points:

Always start with /
Built-in commands handle system functions
Custom commands are Markdown files with prompts
MCP servers can expose prompts as slash commands

Use for: Repeated prompts, project conventions, quick actions, consistency

MCP (Model Context Protocol)

Open standard for standardizing how AI systems integrate with external tools and data sources. MCP servers enable integrations between tooling like claude code and external services like Jira or GitHub.

Key points:

Open standard (not proprietary)
Two-way communication (read and write)
Pre-built servers for popular tools (GitHub, Slack, Postgres)
Cross-platform SDKs (Python, TypeScript)
Adopted by OpenAI, Google DeepMind, and others

Use for: Data access, tool integration, enterprise systems, cross-tool workflows

🎯 Comparison Table

Feature	Skill	Subagent	Command	MCP
Purpose	Reusable actions	Autonomous task execution	Shortcuts	External integrations
Auto-runs	✅ Yes	✅ Yes	❌ Manual	N/A
Location	`./claude/skills/`	`./claude/agents/`	`.claude/commands/`	External servers
File	`SKILL.md`	Agent definition	`.md` file	Server config
Status	✅ Current	✅ Current	⚠️ Deprecated	✅ Current

📚 Resources

Skills:

Skills Documentation - Claude Code

Subagents:

Commands:

MCP:

For detailed explanations, see the full AI Glossary

Prompt Posts: Sharing AI Prompts Through Blog Posts

Ant The Developer — Thu, 15 Jan 2026 16:54:59 +0000

Right now, if you were to create a reusable public prompt, your best bet is using Github and checking the prompt in there. In fact, there are quite a few repos with reusable prompts and all you need to do is search "github [toolname] prompts" and you'll get a great starting list.

My issue is that majority of prompts require their own assessment and tweaking and whatever else to make it work for you. I don't believe most devs check these prompts, read them, or modify them which creates the issue that these prompts aren't as effective as they could be.

So I had this idea, what if instead of "prompts", we create a prompt to create prompts? And what if these directions were written for a human rather than AI?

That's when it hit me, there's a huge wealth of tutorials, guides, etc. that an AI agent could read to generate prompts. What struck me as the next obvious step would be to write a tutorial/guide that a human could follow and an AI could use to generate a prompt.

Why reusable prompts in the first place?

I think this is an easy question to answer because the answer is the same as why we'd want to isolate and create libraries, create open source code, etc.

Reusable prompts are powerful because they can:

keep AI behavior more consistent across codebases/uses
get a better starting point for more focused prompts
enable various common functionalities between codebases

I mean, why not? Being able to port skills, agent definitions, etc. across codebases is great. Being able to keep the same coding standards is the same thing. I'm very much in favor it.

So why blog posts?

I wrote a blog post on best practices for AI-assisted coding as a test for how blog posts could work for prompt generation. The post is essentially a large prompt for an AI tool to use for prompt generation with explanations and step by step instructions for the developers utilizing it.

There are essentially two reasons why you'd want to have this "pre-prompt" with a human explanation instead of static prompts in Github.

The Human Aspect

With AI/agentic coding gaining traction as a productivity tool, it's easy to forget that at some point a human has to be involved. It won't be claude code running its first /init, it'll be a dev (or an agent setup by a dev). The first prompts in a repository will most likely be auto-generated but if you really want to get good value from a properly setup CLAUDE.md or an AGENTS.md, a human will need to be involved in the process.

With that said, that dev may very likely prompt Claude, OpenCode, or whatever other tool like so:

Setup appropriate prompts for this repository. Research prompting best practices. Utilize open source prompts such as the prompts from [some] company.

And be happy with the initial output. However, there will be very little understanding of why prompts are setup the way they are, why those best practices exist. If a developer then keeps up with best practices by themselves, they'll still need to prompt their tool appropriately based on what they've learned.

As a hybrid approach, and a nod to literate programming, I created a blog post that a developer can read so that:

they can understand why the final prompt looks the way it does
they can learn best practices along the way
they have a reference on how to fix possible issues

With a developer having this understanding, writing and fixing prompts should be a lot more straightforward. I'll draw a parallel to reading library documentation when you're hand-coding.

The Pre-Prompt

By utilizing the aforementioned blog post as a prompt for generating prompts, you end up with several adventages including your AI understanding how to customize the prompt for your specific codebase and usecase. It can function as a much better-suited prompt for your codebase in comparison to doing a raw /init.

The AI will be able to digest hints to do research on what libraries are used, what's deprecated, and much more. A copied prompt can't do that much heavy lifting. Since the article is public, you can reuse this pre-prompt for any codebase and even use it to ask your favorite AI tool to adjust its current prompt according to those criteria specified within.

All in all, it's just a better approach to creating prompts.

Note: This is the case right now. I've heard of quite a few users that don't even use CLAUDE.md or use a very thin prompt with a lot of success. That hasn't been my experience but, obviously, we're living in the wild west of AI prompting right now.

Prompts as Public Knowledge

If you're not sold on having public blog posts that function this way, then let me make my argument here.

Publishing blog posts publicly accomplishes several things:

A blog post about "How to Prompt Claude Code for Svelte Components" is easily searchable, linkable, and it can be referenced in discussions and shared with colleagues (across companies/jobs)
- it also provides a super easy way for your AI to see it without requiring auth or access to a folder or what have you
When you publish a prompt, you're inviting others to critique it and provide their own expertise to help improve it
It creates documentation -- A good blog post about a prompt explains why the prompt is structured that way. It explains what problems it solves. It serves as documentation for future use.
It's readily accessible for new projects
It contributes to the collective knowledge. The AI ecosystem is young. When you share what works, you're helping others avoid the trial-and-error phase you went through.

Creating your own

I'm not against using Github at all. Publishing prompt blog posts (prompt post?) on Github may be even a better idea than doing that on a blogging platform; however, I find that Github changes your perception of the prompt post and makes it seem more like just a prompt, eliminating the human aspect.

Creating the prompt post itself isn't terribly difficult. I think the parallel to literate programming is key here. You're writing a post and you're explaining a "template" for the final prompt in easily-digestible parts. I generally like to structure these as:

## Description

Explain what the resulting prompt should do and why.

## Core Logic

Core logic of the prompt goes here along with explanations of each part.

### Standards

For example, this section would explain coding standards such as using or not using classes in your TypeScript code, usage of `any`, and similar.

\`\`\`
## Standards

- DO use Enums for any options, variants, etc.

- DO NOT use `any` in TypeScript code
- DO NOT use classes
\`\`\`

## Expected output

Ensure that you always tell your AI your expectations.

\`\`\`
## Output

Create documentation for coding standards in this codebase
\`\`\`

## Conclusion/More Resources

List out any resources or tips on how to handle certain situations, how to extend the resulting prompt, or list out links to further helpful resources

With this basic structure, you should be able to create a robust prompt post that you, your team, and your AI can fully utilize.

What about you?

What's worked well for you? I've used this system multiple times with unpublished pre-prompts and unfortunately, I don't have access to those anymore (should've made them public!) but this approach has worked for me time and time again to create a solid prompt start for different projects.

Tip: One extra level of inception here would be to reference this post to your AI so it could generate a starting point for your prompt post!

Accessibility labels for content loading in React

Ant The Developer — Mon, 22 May 2023 15:39:51 +0000

I've really been enjoying learning about how to make applications and websites more accessible and recently wondered about how to appropriately label a loader for a side project React app I'm writing. After scouring Stackoverflow answers, and looking at what Bootstrap's solution is, I came across an article by some company called Dockyard. They all conflict in different ways. Finally, I followed an SO link to Fundamental UI. And came up with this idea:

const Loader = () => <div aria-label="Loading">loading...</div>;

const LoadContent = ({ isLoading, children }) => {
  return (
    <div aria-busy={isLoading} aria-live="polite">
      {isLoading && <Loader />}
      {!isLoading && children}
    </div>
  );
};

Here's what it does (as I understand it):

aria-busy lets us indicate that the container is in the process of updating.
aria-live lets us indicate that the element is going to updated. The polite property indicates a background change (this might be a good place to add a prop to indicate if the content is main content, or background content)
aria-label lets us indicate the label for the element.

I made a Sandbox where you can check this out in action.

I'm still getting started with accessibility so I welcome any input on this.

What are your favorite course platforms for furthering your learning?

Ant The Developer — Sun, 24 Apr 2022 13:50:21 +0000

I've seen a few platforms that people have recommended to me but I've had varying success with them and have heard positives/negatives about each. I was wondering what everyone else hits up!

I personally prefer courses by individuals as they seem to be higher quality (eg. Epic React). I do have an egghead subscription but I basically never use it anymore.

How about you all?

The Anatomy Of My Ideal React Component

Ant The Developer — Fri, 11 Mar 2022 18:52:02 +0000

import { useEffect, useState } from 'react'
import { Link } from 'react-router-dom'
import styled from 'styled-components'
import tw from 'twin.macro'

import { USER_ROUTES, useUser } from 'modules/auth'
import { Loader } from 'modules/ui'
import { usePost } from 'modules/posts'

import { EmptyFallback } from './emptyFallback'

const StyledContainer = styled.div`
  ${tw`w-100 m-auto`}
`

const StyledHeading = styled.h1`
  ${tw`text-lg`}
`

type PostProps = {
  id: string
}

export const Post = ({ id }: PostProps): JSX.Element => {
  const [isExpanded, setIsExpanded] = useState(false)

  const { isLoading, isSuccess, post } = usePost({ id })
  const { user } = useUser()

  if (isLoading) {
    return <Loader />
  }

  if (!isLoading && !post) {
    return <EmptyFallback />
  }

  return (
    <StyledContainer>
     <Link to={USER_ROUTES.ACCOUNT}>Back to account, {user.name}</Link>
     <StyledHeading>{post.title}</StyledHeading>
     {post.body}
    </StyledContainer>
  )
}

This is how I write my components and how I prefer to write React. It's a super specific way that works for me - and that includes using styled-components. If you have suggestions on how to improve this structure, I'm all ears. I love to improve how I do things and I greatly enjoy feedback.

I'll drop questions in the article if you'd like to give me feedback on those!

For anyone new to React or JS or development or TS, don't even worry about all that this is doing. I really just wanted to showcase a complicated example.

Note: I wanted to stress this again -- this is what works for me. I'd love to hear about what works for you!

Imports

Does import order matter? Not really. But I like to have rules around them especially for bigger components that might have 20 lines of imports or more. And that happens more than I'd like to admit. My general heuristics are:

React up top no matter what
3rd party library imports (followed by a new line)
internal library imports (and aliased imports)
local imports

// react
import React, { useEffect } from 'react'

// 3rd party libraries
import moment from 'moment'
import styled from 'styled-components'

// internal shared components/utils/libraries
import { ListItems, useItems } from 'modules/ui'

// local
import { EmptyFallback } from './EmptyFallback'

Why? When you deal with more than a handful of imports, it's really easy to get lost in what the file is using. Having conventions around imports makes it easier for me to see what it's using at a glance

Styled Components

No matter what library you use, you are writing your CSS somewhere. I'm a fan of styled-components (we use them at work) and Tailwind (I use it in personal projects). Twin allows you to combine them together -- that way you can write custom CSS if you need to, and Tailwind is great for rapid prototyping and production-ready apps alike. Best of both worlds.

I put these at the top because my components below typically use them. If there are too many styled components, I tend to put them in a co-located styled.ts file.

I also tend to prefix styled components with Styled. Something I learned at work. It quickly distinguishes between styling components and components that do more than that.

const StyledContainer = styled.div`
  ${tw`w-full`}

  background-color: ${COLORS.CONTAINER_BACKGROUND};
`

export const SomeComponent = () => {
  // logic
  const items = useItems()

  return (
   <StyledContainer> {/* styled component that does nothing else */}
    <List items={items} /> {/* component with internal logic */}
   </StyledContainer>
  )
}

Why? I prefer co-located styling but also, put these up top so they're separate from components that have more than styling.

Questions for you: How do you organize your styled components? If you have a file with styled components, what do you call it?

Component Types

I typically name my Component types as ComponentNameProps and ComponentNameReturn where most of the time, I skip the "return" to use JSX.Element (I do use the Return type for hooks though! I'll write about that another day). Check out the React TypeScript CheatSheet which contains majority of the conventions I use for TypeScript and React.

This convention (naming and placement) makes it clear that:

this type belongs to the component
this type isn't shareable
where to find the typing (right above the component)

It's also a stylistic choice not to inline it but you can:

// I don't like this
const SomeComponent = ({ 
  id,
  isEnabled,
  data,
  filter,
  onClick
}: {
  id: string,
  isEnabled: boolean
  data: DataStructureType
  filter: FilterType
  onClick: () => void
}): JSX.Element => {}

// I do like this
type SomeComponentProps = {
  id: string,
  isEnabled: boolean
  data: DataStructureType
  filter: FilterType
  onClick: () => void
}

const SomeComponent = ({ 
  id,
  isEnabled,
  data,
  filter,
  onClick
}: SomeComponentProps): JSX.Element => {}

I feel like I have to constantly re-emphasize: this is what works for me specifically. There's no science or research behind this. It's not "easier to reason about" (which most of the time means "I like this", anyways).

Why? Co-located component types right above the component declaration make it easier for me to see the Component's purpose and signature at a glance

Questions for you: Do you co-locate your component types? Do you prefer inling them?

Component structure

Ok, let's dig into the Component structure. I think components typically have the following parts to them (some more or less, depending on what you're doing):

local state (useState, useReducer, useRef, useMemo, etc.)
non-React hooks and async/state fetching stuff (react-query, apollo, custom hooks, etc.)
useEffect/useLayoutEffect
post-processing the setup
callbacks/handlers
branching path rendering (loading screen, empty screen, error screen)
default/success rendering

More or less, but let's go through them:

// local state
const [isExpanded, setIsExpanded] = useState(false)

// non-react hooks
const { isLoading, post } = usePost({ id })

// useEffect
useEffect(() => {
  setIsExpanded(false) // close expanded section when the post id changes
}, [id])

// post processing
const snippet = generateSnippet(post)

// callbacks and handlers
const toggleExpanded = (e: Event): void => {
  setIsExpanded((isExpanded) => !isExpanded)
}

// branching path rendering
if (isLoading) {
  return <Loading />
}

if (post && !isExpanded) {
  return (
    <StyledContainer>{snippet}</StyledContainer>
  )
}

// default/success render
return <StyledContainer>
  <h1>{post.title}</h1>
  <div>{post.content}</div>
</StyledContainer>

So a few things about this, I set this up so that the logic seems to flow down and we declare as much ahead of time as possible. I think there is quite a bit of wiggle space here because what really matters is declaring variables and using hooks before we render. This is necessary for hooks to work right. If you try to short-circuit a render and skip a hook as a result, React will let you know that's an issue.

I also like to add the handler at the end of that declaration block so I have access to any variables I might need if I convert it to use useCallback. Which is also why I use const func = () => {} instead of function func() {} -- to quickly convert to useCallback and to avoid a mismatch of named functions and lambdas.

We can then safely jump into branching path rendering for loading screens, errors, etc. without worrying about hooks. We can exit the render safely early this way.

And lastly, I keep the default/success render at the bottom.

Why It's a lot to cover but honestly, it's all personal preference influenced by React's requirement to always run all hooks in a component.

Question Does this differ much from your standards?

Potential For Refactor

You might notice that my original component doesn't have a useEffect or the post-processing examples. Why is that?

Typically, if I have to do some lifting in a component to get data in a specific state, or I have variables that relate to each other, I like to hide that in a hook.

For example:

type UsePostProps = {
  id: string
}

type UsePostReturn = {
  isExpanded: boolean
  post: PostType
  isLoading: boolean
  toggleExpanded: () => void
}

export const usePost = ({ id }: UsePostProps): UsePostReturn => {
  const [isExpanded, setIsExpanded] = useState(false)
  const { isLoading, data } = useQuery('cache', getPost)

  useEffect(() => {
    setIsExpanded(false)
  }, [id])

  const post = !isLoading && formatPost(data)

  return {
   isExpanded,
   toggleExpanded,
   isLoading,
   post,
  }
}

Why I'm not sure. I don't like big components, I don't like components that do too much so I split logic up into hooks however feels right to me.

Question How do you feel about wrapping API calls in custom hooks by default? eg. any unique call has its own hook that handles data transformation, related state, and the fetching. And do you prefer to have this logic inside of a component?

Wondering about folder structure?

I made a React application structure video on that topic. Though, in hindsight, it has a few syntax errors I didn't notice while recording.

What are your favorite non-dev activities to do after a solid day of coding?

Ant The Developer — Thu, 18 Feb 2021 15:32:05 +0000

I love coding but I like to also switch things up to keep my mind fresh and to relax. What do you like to do in your time off? Would you recommend it to the rest of us?

I love to:

read and write fiction
play games and make a podcast about it
take long baths with luxury bath bombs (those that have like flower petals or little crystals in them :D )
talk to my friends about my day on my Discord server's voicechat

7 Little Things I Learned In January

Ant The Developer — Mon, 01 Feb 2021 15:43:23 +0000

I have a dozen half-written articles on dev.to and many more scattered across the universe. It's daunting and overwhelming trying to write something good. When these articles come out, I know they'll be good but until I get there, I figured I'd kick off a new personal series :)

1. Use JQ to get info from `package.json` quickly

JQ is a command line utility that can explore JSON files. When I found out just how easy this utility is to install (every package manager has it) and to use, I created two aliases to help me with every day tasks:

# npmscr will print out a list of package.json scripts
alias npmscr="jq '.scripts' package.json"

# npmver will print out the package.json version
alias npmver="jq '.version' package.json"

2. What `git pull` does

I had a conversation with a fellow dev about this. And honestly, even while researching this for this article, the behavior is a tad confusing.

Out right, this is what git pull does:

git pull

# is equivalent to
git fetch && git merge FETCH_HEAD

We fetch data from remote and then merge it into our local.

The confusing part to me is if git fetch fetches only data for our current branch or if it does a blanket git fetch origin equivalent.

3. `console.debug`

I had no idea about console.debug. I've always used console.log to log any data for debugging. The biggest difference? It shows up differently in your console!

There's literally a special section (at least in chrome devtools) for debugging statements. In any application with regular logging or just a ton of random logs, this is a super easy way to split this stuff apart.

Super happy that one of my colleagues showed this to me during a pairing session.

console.debug({ thatOneTrickyVar });

4. Pair programming is a skill to be taught/learned

It might sound obvious to some and baffling to others. I started at a new job recently and had a conversation about this with a fellow programmer and later on, with one of my friends who is just starting out. I had been so used to pairing with my colleagues, that it didn't occur to me that this helped me a ton to get better at pairing.

So what's there to learn? A balance between asking questions, observing, giving input, and a slew of other things.

From my experience, some people tend to micro-manage in either place (as a driver or navigator...or whatever the titles are), some tend to be too hands off, some people ask too many questions and some none at all. It's really an interesting aspect of programming.

I think a lot of programmers are opposed to pairing; however, the benefits of pairing well are incalculable (and probably good for another article :) ). Strangely, from anecdotal experience, senior people have more issues with this than junior people.

5. Naming cheatsheet

Okay, okay, probably all of you already know about the naming cheatsheet that Kent C. Dodds tweeted about recently, but it's worth pointing out.

It's a nice little readme specifying various naming conventions. I personally don't agree with some of them but majority of the rules specified, I already follow.

Conventions are extremely powerful, especially in a team setting.

6. Basic TypeScript typing for React

I've used TypeScript with React only passingly but I've used TypeScript quite a bit in Angular, for writing libraries, and just for fun. One thing that's always scary is figuring out the basics. They're often unavailable. So here's the gist of what I've learned:

import React from 'react';

// type is `React.FC` (for "Functional Component")
const MyComponent: React.FC = () => { 
  return (
    <h1>Hi!</h1>
  );
};

// React.FC is a generic
interface IMyComponentProps {
  color: string;
  children: React.ReactNode; // React.ReactNode is any react node
}

const MyComponent: React.FC<IMyComponentProps> = ({ color = '#000',  children }) => {
  return (
    <>
      <h1 style={{ color }}>Hi!</h1>
      {children}
    </>
  );
};

7. You can run Cypress without a server

I've been used to writing Cypress tests as e2e tests where I had full ability to run a backend server. I recently found out that it's fairly straightforward to write mocks in Cypress.

Using routes:

const mockResponse = { id: 1, content: 'Text' }
cy.route('/api/actual/endpoint', mockResponse)

The syntax allows for all kinds of specifications from capturing via wildcards cy.route('/api/posts/*') to specifying the protocol first like so: cy.route('POST', '/api/posts/*', mockResponse).

You can even pass in a function to handle/generate a response or even assert on the request body.

cy.route is deprecated though so you can always jump into using cy.intercept. The main reason I'm not using it is because last time I checked, intercept had a bug where it didn't match wildcards (the * in URLs). But cy.intercept is super powerful. Go checkout cy.intercept docs for more info.

The point being, Cypress lets you run your frontend without hitting your backend if necessary.

Demystifying the find command

Ant The Developer — Mon, 07 Dec 2020 15:12:37 +0000

📃 Cheatsheet

List all files and folders in current directory:

find

Find files/folders that match a pattern:

find -name "*pattern*"

Run a command per result. Substitute command with your actual command.

find . -name "*pattern*" -exec command {} +;

What is find?

find is a command I rarely come across but it turns out, it's one of the more powerful commands in Unix-like system. Find, at its basest, lists all the files and folders in a directory. Kind of like a recursive ls. This can be piped into any command. But find also has other features like filtering and the ability to execute a command on each matching file.

Find is also sometimes used as the "backend" for fuzzy file searchers. For example, fzf uses find under the hood to employ fuzzy search in the command line (which is super useful).

Plain "find"

Using find alone will print out all directories and files located under your current working directory. This is useful for piping or other actions.

find

Just for the sake of completeness, you can also specify a path but find will assume you want to search your current directory by default.

find /path/to/dir

Find file or directory by pattern

To find a file or directory, one can specify its name and pass it in as an argument. Both files or directories will match.

find -name "package.json"
find -name "node_modules"

Find will return any matches including nested directories. Note that the match isn't done on the path but on the actual directory/file name itself.

You can also specify a pattern using * as a wildcard like so:

find -name "pattern*"
find -name "*.spec.js"

Execute a command on all found files

find allows you to execute logic on every single match it finds via the -exec flag. There are 2 ways to execute commands: once on all the results or run it per result.

Here's once for all results:

# substitute any kind of command for the keyword "command"
find . -name "*.js" -exec command {} \;

The command has several parts. We're already familiar with the pattern matching so next comes the -exec flag. After exec, you can type out your command and end it with \;. The {} braces will be substituted with the find results.

To run the command separately per result, end your command with + instead of \;.

# substitute any kind of command for the keyword "command"
find . -name "*.js" -exec command {} +

Using Postgres FOR loop to generate data

Ant The Developer — Fri, 26 Jun 2020 22:08:09 +0000

I don't know about you but I often need a 100 of something in my database to properly test a page. If my UI isn't developed yet to handle that action or the count of something is too large, that's when I turn to SQL.

Today, for instance, I needed to test virtual scrolling and I didn't have enough data locally to trigger that behavior so I wrote a quick loop in Postgres to generate a 100 items:

DO $FN$
BEGIN
  FOR counter IN 1..100 LOOP
    RAISE NOTICE 'Counter: %', counter;

    EXECUTE $$ INSERT INTO items(name, active) VALUES ('Test item ' || $1, true) RETURNING id $$ 
      USING counter;
  END LOOP;
END;
$FN$

If you've followed me for a while, you'll recognize this loop from the wild SQL query I had to write for work. However, this loops is much simpler. And this item would generate 100 items in my database with sequentially numbered names.

Let's go through this query real quick

`DO` block

A DO block creates a special block that can execute some SQL. It's start and end is denoted by $FN$ in my query but you can use any delimiter that starts and ends with a dollar sign. So $DO$ works, as does $MY_FUNKY_LOOP$ .

`BEGIN...END`

BEGIN and END create the section of the loop which runs the actual SQL statement. You can also have a DECLARE section which lets us assign and create some variables. We don't need it here.

`FOR LOOP`

The FOR counter IN 1..100 LOOP lets us create a for loop. Postgres has a handy way of creating ranges via the .. syntax (so 1..100 is 1 through 100). The current value of the range in the iteration is saved in the counter variable.

`RAISE NOTICE`

This is the console.log of Postgres :)

`EXECUTE $$ $$ USING`

EXECUTE will literally just execute the SQL between $$. What EXECUTE lets us do is specify USING which is used for variable substitution.

I like to think of this as a little self-executing function where USING lets us specify the parameters and execute runs the SQL and substitutes our parameter in the statement.

So as counter increases, the item name will increment as well.

Why even use this?

It's just a super handy small snippet for generating data. 🤷

What's cool is that the more I learn SQL, the more I find myself using these types of loops and logic and adding onto them. There's nothing stopping us from using some sort of random generator to create better varied data for development or for generating data in a staging environment.

What are your favorite themes for your IDE/Shell?

Ant The Developer — Tue, 05 May 2020 17:33:52 +0000

I'm on the hunt for a new VIM/VSCode/ZSH theme, I'd love to hear what your favorite ones are! (Mine will be in the comments)

Demystifying GREP

Ant The Developer — Thu, 09 Apr 2020 23:16:43 +0000

📃 Cheatsheet

Search for a keyword in a file:

grep keyword file.txt

Search using a regular expression:

grep -E 'regex' file.txt

Search for a keyword in a directory:

grep -r keyword ./directory/path

Combine multiple flags/options to search through a directory, display line numbers, and use regex:

grep -Enr 'regex' ./directory/path

🔎 What is grep?

Grep is a CLI utility for plain text searches with regex (regular expressions). It's like a Ctrl/Command + F but through a bunch of files and in the command line.

It's another one of those ancient utilities that have proliferated through all Linux and Unixy distributions. Similar to Rsync and tar that I've talked about in the past.

Fortunately, unlike rsync or tar, grep requires a lot less flags and knowledge of the tool to be very productive with it.

Note: Are you on Windows? Check out my article on "how to 'grep' in Powershell"

📄 Searching for a keyword in a file

If you're in the command line and you don't necessarily want to open a file, or you're dealing with an enormous file, it can be very handy to look for just one line of text using grep.

grep searchkeyword file.txt

Grep will return all the lines containing the text. Depending on your grep variant, you might get line numbers, the keyword highlighted, and other fun information.

🔬 Searching using regular expressions with the `-E` flag

Need to use a regular expression because you're a pro at those? Wrapping a regex in quotes will do it most of the time; however, some syntax isn't supported this way so you have to use the -E flag. For example:

grep '^2020-0[0-4]' file.txt

This will work just fine, the [] syntax is supported in basic regex mode; however, specifying occurrences with {} won't work so I recommend defaulting to the -E flag for any regex so you can do neat stuff like this:

grep -E '[0-9]{4}-[0-9]{2}-[0-9]{2}' logfile.txt

This regex will fail in basic mode but the extended mode will match any yyyy-mm-dd date anywhere within your text.

📂 Searching through multiple files/directory

Grep lets you also recursively search through many files and directories.

grep -r searchkeyword directoryName

Grep will return all of the matching lines and tell you in which files they were.

🏁 More flags

Grep has a great deal of options. Their manual page is very long and I suggest giving it a look when you feel like grep's basic capabilities just aren't enough for you.

Here's the syntax to add or combine flags when using grep:

grep -flags searchkeyword directoryOrFilename
grep -ir antonin ./documents

In the example, -ir combines both the i and the r flag. Similarly, -Er would let us recursively search with extended regex.

Quick run down of some of these useful flags:

i - case insensitive flag
n - show line numbers in the matches
o - print only the matches, and not the lines (particularly useful with regex)

What are your top WFH/Remote working tips?

Ant The Developer — Wed, 11 Mar 2020 16:32:37 +0000

So many people are having to work from home or work remotely due to COVID-19, what are your tips for them?

Here are mine:

Get dressed -- doesn't have to be formal, just avoid pajamas or bathrobes
set a regular schedule as you would in office -- even if it's an unconventional schedule
work in a space separate from your relax/wind down place -- working on a couch has always been a productivity killer
take breaks to make coffee

DEV Community: Ant The Developer

Agentic AI Glossary Cheatsheet

📃 Quick Reference

Skill

Subagent

Command (Deprecated)

🔑 Term Definitions

Skill

Subagent

Command (Deprecated - Use Skills)

MCP (Model Context Protocol)

🎯 Comparison Table

📚 Resources

Prompt Posts: Sharing AI Prompts Through Blog Posts

Why reusable prompts in the first place?

So why blog posts?

The Human Aspect

The Pre-Prompt

Prompts as Public Knowledge

Creating your own

What about you?

Accessibility labels for content loading in React

What are your favorite course platforms for furthering your learning?

The Anatomy Of My Ideal React Component

Imports

Styled Components

Component Types

Component structure

Potential For Refactor

Wondering about folder structure?

What are your favorite non-dev activities to do after a solid day of coding?

7 Little Things I Learned In January

1. Use JQ to get info from package.json quickly

2. What git pull does

3. console.debug

4. Pair programming is a skill to be taught/learned

5. Naming cheatsheet

6. Basic TypeScript typing for React

7. You can run Cypress without a server

Demystifying the find command

📃 Cheatsheet

What is find?

Plain "find"

Find file or directory by pattern

Execute a command on all found files

Other demystifying articles

Using Postgres FOR loop to generate data

DO block

BEGIN...END

FOR LOOP

RAISE NOTICE

EXECUTE $$ $$ USING

Why even use this?

What are your favorite themes for your IDE/Shell?

Demystifying GREP

📃 Cheatsheet

🔎 What is grep?

📄 Searching for a keyword in a file

🔬 Searching using regular expressions with the -E flag

📂 Searching through multiple files/directory

🏁 More flags

What are your top WFH/Remote working tips?

1. Use JQ to get info from `package.json` quickly

2. What `git pull` does

3. `console.debug`

`DO` block

`BEGIN...END`

`FOR LOOP`

`RAISE NOTICE`

`EXECUTE $$ $$ USING`

🔬 Searching using regular expressions with the `-E` flag