DEV Community: Ladipo Samuel

Building an SPL Token: Creating the Mint

Ladipo Samuel — Sat, 05 Sep 2026 15:30:18 +0000

Now that we have a mental model of how Solana works, it’s time to actually use it.

We’ve talked about accounts holding state, programs containing the logic, instructions telling those programs what to do, and transactions bringing those instructions together. Creating an SPL Token Mint is a good place to see all of those concepts working together.

In this part, we’ll create and initialize an SPL Token Mint on Solana Devnet, but more importantly, we’ll break down what is actually happening underneath the code.

So, what exactly is a Mint?

If I tell Solana to give someone 100 of a particular token, Solana first needs to know what that token is. What defines it? How divisible is it? How many units currently exist? Who has the authority to create more? That is where the Mint Account comes in.

A Mint Account represents a particular type of token on Solana. It stores information about that token such as its current supply, decimals, mint authority and optional freeze authority. It does not store how many tokens I personally own. That belongs somewhere else, which we’ll get to when we talk about Token Accounts and ATAs.

A simple way to separate the two is this: the Mint tells us what token exists, while a Token Account tells us how much of that token a particular owner holds. Before looking at any code, the complete process for creating our Mint looks like this:

Connect to Solana Devnet
Load our wallet
Generate a new keypair for the Mint
Calculate how much space a Mint Account needs
Calculate the lamports required for the account
Ask the System Program to create the account
Ask the Token Program to initialize it as a Mint
Put both instructions inside a transaction
Sign the transaction
Send and confirm it on Solana

There are quite a few SDK functions involved when implementing this, but underneath all that syntax, this is really what the entire spl_init.ts file is doing.

Starting with the wallet and Mint address
We first load our wallet and turn it into a signer. The wallet is important because someone has to pay the transaction fee and authorize the operations that require a signature.

const signer = await createKeyPairSignerFromBytes(
  new Uint8Array(wallet)
);

The exact SDK function isn't the important part here. What matters is that we now have a signer that represents our wallet and can be used when constructing the transaction.
Next, we generate a new keypair for the Mint.

const mint = await generateKeyPairSigner();

There is an important distinction here. Generating this keypair does not create anything on Solana. At this point, we simply have a new keypair locally and a public address that we intend to use for our Mint. Solana does not have an account at that address yet. We still have to create one.

Creating the account before creating the Mint
This is where Solana's account model becomes important. Programs contain the logic, while accounts hold state. Since a Mint needs to store information like supply, decimals and authorities, that information needs somewhere to live.

Before creating the account, we calculate how much storage a Mint requires and how many lamports are needed for an account of that size.

const mintSpace = getMintSize();
const rent = await rpc
  .getMinimumBalanceForRentExemption(BigInt(mintSpace))
  .send();

Now we know the amount of space to allocate and how much to fund the account with.
The next instruction asks the System Program to create the account.

const createAccountIx = getCreateAccountInstruction({
payer: signer,
newAccount: mint,
lamports: rent,
space: mintSpace,
programAddress: TOKEN_PROGRAM_ADDRESS,
});

Reading this without focusing too much on the syntax makes it fairly straightforward. Our wallet is paying, mint is the new account we want to create, lamports funds it, space determines how much storage it gets, and TOKEN_PROGRAM_ADDRESS says that the Token Program will own the account.
That last part is important because on Solana, an account's owner is a program, not necessarily the person we might casually describe as owning something. The owner program is the program allowed to modify that account's data according to its rules.

At this stage, however, we have only described how the account should be created. We still haven't told the Token Program that this account should behave as a Mint.

Turning the account into a Mint

This is where the second instruction comes in.

const initializeMintIx = getInitializeMintInstruction({
  mint: mint.address,
  decimals: 6,
  mintAuthority: signer.address,
  freezeAuthority: signer.address,
});

The first instruction says, “create this account.” The second says, “initialize this account as a Mint.”

This is also where we configure some of the Mint's properties. With decimals: 6, one whole token can be represented as 1,000,000 base units. We also set our wallet as the mintAuthority, which gives it the authority to create new units of this token.

One distinction worth understanding here is Token Program ownership versus mint authority. The Token Program owns the Mint Account and enforces the rules around how its data can change. Our wallet being the mint authority simply means it has permission, under those rules, to authorize the creation of new token units. They are two completely different responsibilities.

Instructions are not transactions

Another useful distinction is that creating these instruction objects has still not changed anything on-chain.
An instruction is essentially a description of an operation we want a Solana program to perform. At this point, we have prepared two of them: one for the System Program to create the account and another for the Token Program to initialize it.
We then put both into a transaction, and their order matters. The System Program has to create the account before the Token Program can initialize it as a Mint.

Conceptually, the transaction looks like this:
Transaction

  Instruction 1
  System Program → Create Account

  Instruction 2
  Token Program → Initialize Mint

The transaction also needs a fee payer and a recent blockhash. The fee payer is the account paying the network fee, while the recent blockhash gives the transaction a validity window and helps prevent old transactions from being replayed indefinitely.
Once everything is assembled, the required signers sign the transaction. Signing is essentially authorization. It proves that the required keys approved the transaction.

Only after we send that signed transaction to Solana does the work we've been preparing actually happen on-chain.
The System Program creates the account first, then the Token Program initializes it as a Mint. Once the transaction is confirmed, we get our Mint address and transaction signature. The Mint address identifies our newly created token Mint, while the transaction signature identifies the transaction and can be used to inspect what happened on-chain.

Have we created any tokens yet?

No, and this is probably the most important distinction in the entire process.

Creating a Mint is not the same thing as minting tokens.
At this point, we have defined a token on Solana. It has an address, decimals and authorities, but its supply is still zero. We haven't created any actual token units or given them to anyone yet.
The way I like to think about the state we're currently in is:
Mint Account
What token exists? → Done

Token Supply
How many tokens have been created? → 0

Token Account
Who holds how many tokens? → Not created yet
So if I had to explain the whole spl_init.ts file in one sentence, it would be this:

We generated an address for our Mint, asked the System Program to create an account there, asked the Token Program to initialize that account as a Mint, then packaged those instructions into a transaction, signed it and sent it to Solana.
We now have the foundation for our token, but an address alone isn't very descriptive. We still need a way to associate information like a name, symbol and URI with it.
That is what we will treat next with metadata.

Building on Solana with Turbin3: Understanding the Architecture First

Ladipo Samuel — Fri, 04 Sep 2026 17:37:56 +0000

I recently started building with Turbin3, and before getting deeper into SPL tokens, NFTs and Anchor, I wanted to properly understand what is actually happening underneath the code.

I’ve worked with other ecosystems before, including Sui and Cardano, and one thing I’ve noticed is that every blockchain has its own way of structuring things. With Solana, concepts like accounts, programs, instructions, transactions, PDAs and CPI come up almost everywhere. Once I started seeing how they connect instead of learning each one separately, the architecture became much easier to understand.

So before getting into tokens and writing more code, I wanted to start with the mental model I currently use for Solana.

The simplest way I understand Solana

When I perform an action on Solana, I picture the flow like this:

Wallet
   ↓
Transaction
   ↓
Instruction(s)
   ↓
Program
   ↓
Accounts
   ↓
State changes

My wallet signs a transaction. That transaction contains one or more instructions, and each instruction tells a particular program what action I want it to perform and which accounts are involved. The program processes that instruction, and if everything is valid, the relevant accounts are updated.

That simple flow helped me connect most of the concepts I was learning.

Programs contain logic, accounts contain state

This was one of the first distinctions that made Solana easier for me to reason about.

A program contains the logic and rules for what can happen, while accounts are where data or state lives.

For example, imagine I’m building an escrow. The program could contain the rules for depositing, releasing and refunding funds, while an account could store information such as the sender, receiver, amount and current status of that escrow.

Coming from backend development, I loosely think about it like this:

Program ≈ backend logic
Account ≈ stored state/data

It’s not a perfect comparison, but it gives me a useful starting point.

Another thing that initially needed some clarification was account ownership. When we say an account is owned by a program, we are not talking about the person who controls a wallet. The owner is the program that has authority to modify that account’s data according to Solana’s rules.

Instructions tell programs what to do

Once programs and accounts make sense, instructions become much easier to understand.

An instruction is basically a request for a specific program to perform an action. For example:

System Program → Create an account
Token Program  → Mint tokens
Token Program  → Transfer tokens

An instruction needs to identify the program being called, the accounts involved, and the data describing what should happen.

So I think about an instruction as:

Program  → Who should execute this?
Accounts → What accounts are involved?
Data     → What should the program do?

The accounts passed into an instruction can also have different roles. A signer means authorization from that account is required, while a writable account is one whose state may be changed by the instruction.

Transactions bring instructions together

An instruction describes an action, but a transaction is what packages one or more of those actions together and sends them to Solana.

For example, when we create an SPL Token Mint later, one transaction can contain:

Transaction
   │
   ├── Instruction 1
   │      System Program → Create Account
   │
   └── Instruction 2
          Token Program → Initialize Mint

This is something I found useful to understand early: creating the account and initializing it as a Mint are actually two different operations, even though we can put both instructions inside the same transaction.

The transaction also contains things like the required signatures, a fee payer and a recent blockhash. The fee payer pays for the transaction, while the recent blockhash helps keep the transaction fresh and prevents old transactions from being reused indefinitely.

Once the required signatures are there, the transaction is sent to the network, validators process its instructions, and the state of the relevant accounts can change.

Where do PDAs fit into this?

PDAs, or Program Derived Addresses, sounded more complicated to me at first than they actually turned out to be.

A PDA is an address derived from:

Program ID + Seeds + Bump → PDA

Unlike a normal wallet address, a PDA has no private key. It is derived to be off the Ed25519 curve, so there isn’t a normal keypair sitting somewhere that can sign for it.

Instead, the Solana runtime allows the program associated with that PDA to act with its authority when the correct seeds and bump are provided.

This makes PDAs useful for things like program state, vaults and escrows.

For example, an escrow program could derive an address using:

"escrow" + user wallet + escrow id

Because the derivation is deterministic, the same inputs will always lead to the same PDA.

The bump is an extra byte used during this process to find a valid off-curve PDA.

One distinction I also found important is that deriving a PDA does not create an account. Derivation only gives us an address. If we want an actual account there to hold data or lamports, that account still needs to be created.

CPI is how programs work with other programs

The last piece of this mental model is CPI, or Cross Program Invocation.

CPI simply means one Solana program calling another program.

Suppose I build an escrow program that needs to transfer tokens. My program doesn’t need to implement the Token Program’s functionality itself. It can invoke the Token Program:

Escrow Program
      ↓ CPI
Token Program
      ↓
Transfer tokens

That ability for programs to invoke other programs is a big part of how programs compose on Solana.

PDAs also become useful here. If a PDA needs to act as an authority during a CPI, the program can provide the PDA’s seeds and bump, allowing the runtime to verify that the PDA was derived by that program.

How I approach Solana code now

One thing I’m trying to avoid while learning Solana is memorizing SDK functions without understanding why I’m calling them.

Instead, when I see a piece of Solana code, I first try to figure out:

What program am I calling?
What accounts does it need?
Which accounts need to sign?
Which accounts can change?
What instruction am I asking the program to perform?
Is another program being called through CPI?
Is there a PDA involved?

Once I can answer those questions, the SDK functions start to feel more like tools for expressing something I already understand rather than random functions I need to memorize.

So the mental model I’m taking forward is still:

Wallet
   ↓
Transaction
   ↓
Instruction(s)
   ↓
Program
   ↓
Accounts
   ↓
State changes

With two important additions:

Program A → CPI → Program B

Program ID + Seeds + Bump → PDA

That’s the foundation I wanted to get right before moving deeper into SPL tokens and NFTs.

In the next part, we’ll put this architecture into practice by creating an SPL Token Mint on Solana Devnet. That’s where we’ll see the System Program, Token Program, accounts, instructions, signers and transactions actually come together in code.

dockerizing your fastapi application

Ladipo Samuel — Thu, 16 Jul 2026 09:30:20 +0000

Ladipo Samuel

Jul 16

Docker Series Part 3: Dockerizing Your First Application.

#beginners #docker #python #tutorial

5 min read

Docker Series Part 3: Dockerizing Your First Application.

Ladipo Samuel — Thu, 16 Jul 2026 09:30:02 +0000

In the first two parts of this series, we focused on understanding Docker.

We talked about why Docker was created, why the infamous "works on my machine" problem existed for years, and how Docker solved it. We also looked behind the scenes at Docker's architecture and understood the relationship between the Docker Client, Docker Engine, Docker Hub, Images, and Containers.

Now it's time to put all of that knowledge into practice.

Today, we'll take a simple FastAPI project and package it into a Docker Image that can run consistently across different environments. The project itself is intentionally small because the goal isn't to learn FastAPI: it's to understand how Docker packages applications.

I'll also attach the GitHub repository used in this article so you can clone it and follow along.

github link: https://github.com/ladicodes/docker-demo

Our Project

Before introducing Docker, our project looks like this:

docker-workshop-api/
│
├── main.py
├── requirements.txt
└── README.md

At this stage, it's just another Python application.

It works because our machine already has Python installed, along with every dependency the project requires.

But if we send this same project to another developer, they may run into completely different problems:

Different Python versions
Missing dependencies
Different operating systems
Different environment configurations

This is exactly the kind of inconsistency Docker was designed to eliminate. Instead of sending just our source code, Docker allows us to package the entire runtime environment alongside the application.

The Dockerfile: Docker's Instruction Manual
Docker doesn't magically understand how to package your application. You have to tell it exactly what to do: that's where the Dockerfile comes in.

A Dockerfile is simply a text file containing step-by-step instructions Docker follows to build an Image.

Let's build ours one instruction at a time.

Step 1: Choosing a Base Image
FROM python:3.12-slim

Every Docker Image starts from another Image. Instead of installing Python ourselves, we're using the official Python Image published on Docker Hub.
You'll also notice we're using python:3.12-slim instead of the regular Python Image.

The slim variant removes unnecessary packages while keeping everything needed to run Python applications. This produces smaller Images, which means faster downloads, quicker deployments, and lower storage usage. We'll go much deeper into Image optimization in Part 4.

Step 2: Setting the Working Directory
WORKDIR /app

Think of this as running:

cd /app

inside the container.

From this point onward, every instruction in the Dockerfile executes relative to this directory. Having a dedicated working directory keeps the Image organized and prevents files from being scattered throughout the filesystem.

Step 3: Copying Dependencies First
COPY requirements.txt .

This line copies only the dependency file into the Image. You might be wondering: Why not copy everything immediately?
The answer is Docker Layers. Docker builds Images layer by layer.

If your dependencies rarely change but your application code changes frequently, Docker can reuse the dependency layer during future builds instead of reinstalling everything from scratch. That dramatically speeds up build times. It's a small decision now that saves minutes later in larger projects.

Step 4: Installing Dependencies
RUN pip install --no-cache-dir -r requirements.txt

The RUN instruction executes commands while the Image is being built. Here, Docker installs every package listed in requirements.txt.

The --no-cache-dir flag tells pip not to keep unnecessary installation cache files, helping reduce the final Image size. Every instruction like this becomes part of the final Image.

Step 5: Copying the Application
COPY . .

Now that our dependencies are installed, we copy the rest of the project into the Image. At this point, Docker has everything it needs:

Application code
Dependencies
Configuration
Runtime environment

The application has officially been packaged.

Step 6: Documenting the Application Port
EXPOSE 8000

This tells anyone using the Image that the application is expected to listen on port 8000. It's worth noting that EXPOSE doesn't automatically make the application accessible from your computer. It simply documents which port the application uses inside the container.

We'll map that port when we actually run the container.

Step 7: Starting the Application
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

This instruction defines what should happen whenever a container starts from this Image. In our case, Docker launches the FastAPI application using Uvicorn.

You may notice the application listens on:

0.0.0.0
This often confuses beginners. 0.0.0.0 isn't the address you'll open in your browser. Instead, it tells the application to listen on all available network interfaces inside the container.

From your own computer, you'll access the application through:

http://localhost:8000, by entering uvicorn main:app --reload

because Docker maps your computer's port to the container's port.

Building Our First Docker Image

Now that our Dockerfile is complete, it's time to package the application.

Run:

docker build -t docker-workshop-api .

Let's quickly break this command down.

docker build: Builds a Docker Image.

-t: Assigns a name (tag) to the Image.

docker-workshop-api: The name we'll use whenever we want to create containers from this Image.

dot(.): Perhaps the most overlooked part of the command. The dot tells Docker to use the current folder as the build context, allowing it to locate the Dockerfile and every file referenced by COPY.
Once the build completes, you can confirm the Image exists by running: docker images

You'll now see your newly created Image listed locally. At this point, nothing is running yet. You've simply created the package.

Creating a Running Container

Now we can create a running application from that Image.

docker run -p 8000:8000 docker-workshop-api

This is where many beginners accidentally mix up Images and Containers.

Remember:

An Image is the package. A Container is the running instance of that package.

The docker run command creates a brand-new Container from the Image before starting the application.

The -p 8000:8000 flag maps:

Your Computer (8000)
│
▼
Container (8000)

This allows your browser to communicate with the application running inside Docker.

If everything goes well, you'll see something similar to:

INFO: Uvicorn running on http://0.0.0.0:8000

Although the application listens on 0.0.0.0 inside the container, you should open:

http://localhost:8000/docs

From there, FastAPI's interactive documentation lets you test every endpoint and confirm your application is running successfully inside Docker.

Where We Go From Here

Congratulations.

You've just Dockerized your first application.

More importantly, you've connected the concepts we've covered throughout this series:

Python Project
│
▼
Dockerfile
│
▼
docker build
│
▼
Docker Image
│
docker run
│
▼
Docker Container
│
▼
Running Application

Understanding this flow is far more valuable than memorizing commands because every Docker project, whether it's a personal project or a production system follows this same journey.

But we're not done yet. Our application works, but there are still important questions to answer.

Why are some Docker Images over 1GB, while others are only a few hundred megabytes?

Why do some projects rebuild in 5 seconds, while others take 5 minutes?
How do production teams build Images that are smaller, faster, and more secure?

That's exactly what we'll explore in Part 4, where we'll dive into Docker layers, caching, .dockerignore, base Images, and practical techniques for optimizing Docker Images like experienced engineers.

See you in the next part.🚀

part 2 on understanding docker

Ladipo Samuel — Mon, 06 Jul 2026 17:53:03 +0000

Ladipo Samuel

Jul 6

Docker Explained (Part 2): Understanding Docker's Architecture, Images & Containers

#architecture #beginners #docker #tutorial

4 min read

Docker Explained (Part 2): Understanding Docker's Architecture, Images & Containers

Ladipo Samuel — Mon, 06 Jul 2026 17:29:51 +0000

One of the biggest mistakes people make when learning Docker is jumping straight into commands without understanding what's happening behind the scenes.
You'll see people type commands like:
docker run nginx

The application starts, everyone is happy, and they move on. But have you ever stopped to ask yourself: what actually happens after I press Enter?
It might seem like Docker is magically running your application, but it's actually following a simple process every single time.

Think of it like this:
You
│
▼
Docker Client
│
▼
Docker Engine
│
▼
Docker Hub (if needed)
│
▼
Docker Image
│
▼
Docker Container
│
▼
Running Application

Let's break this down.

Docker Client
The first component your command interacts with is the Docker Client.
Think of it as the messenger between you and Docker.

When you type: docker run nginx
The Docker Client doesn't create containers or download images. Its only responsibility is to receive your command and send it to the Docker Engine. A simple example is ordering food through an app. You place your order using the app, but the app doesn't prepare your meal. It simply sends your request to the restaurant: the Docker Client works exactly the same way.

Docker Engine
Once the Docker Client receives your command, it forwards it to the Docker Engine. If the Docker Client is the messenger, then Docker Engine is the brain. This is where the work happens.

The Docker Engine is responsible for:

Building Docker Images
Creating and starting Containers
Managing Docker Networks
Managing Docker Volumes
Pulling Images from Docker Registries

Without the Docker Engine, Docker simply cannot function. The first thing the Engine asks itself is: "Do I already have this image?"
If the answer is yes, Docker continues. If the answer is no, Docker needs somewhere to download it from. That's where Docker Hub comes in.

Docker Registry (Docker Hub)
A Docker Registry is simply a place where Docker Images are stored. The most popular registry is Docker Hub. Think of Docker Hub as GitHub but instead of hosting source code, it hosts Docker Images.
If Docker Engine can't find an image locally, it automatically reaches out to Docker Hub, downloads the image, stores it on your computer, and then continues the process. The nice thing is that Docker only downloads an image once.

The next time you run the same image, Docker simply uses the local copy, making the process much faster. Understanding this explains why your very first Docker command usually takes longer than every command after it.

Docker Images != Just a Blueprint
One of the most common explanations you'll hear is: "A Docker Image is a blueprint."
While that's true, it doesn't tell the whole story. A Docker Image is a complete, read-only package that contains everything your application needs to run.

That includes:

Your application code
Runtime (Python, Node.js, Java, etc.)
Dependencies
Required libraries
Configuration
Operating system packages

Think of it as a snapshot of your application at a particular point in time. Once an image is built, Docker treats it as immutable, meaning it doesn't change. If you modify your application, Docker doesn't update the existing image. Instead, it creates a completely new image.
At first, this might sound inefficient. In reality, it's one of Docker's biggest strengths. Because Images never change, every developer, testing environment, CI/CD pipeline, and production server runs exactly the same package.
That's one of the biggest reasons Docker became so popular: It removed the uncertainty of different environments.
Another important thing to know is that Images are not running. They simply exist, waiting to be used. You can think of an Image as a packaged application that's ready to be launched whenever you need it.

Docker Containers: Where Your Application Comes Alive
Here's something many beginners don't realize: docker never runs an Image directly. Instead, it creates a Container from that Image. A Container is simply the running instance of a Docker Image. Unlike Images, Containers are alive; they consume CPU; they use memory; they process requests; they respond to users.
They are the part that's actually executing your application. One of Docker's biggest advantages is that a single Image can create multiple Containers.

For example:

Every container starts from the exact same Image. That's why Docker delivers consistency. Instead of creating three different applications, Docker simply creates three running instances from the same package.
Containers are also designed to be temporary. If a container crashes, becomes corrupted, or is deleted, Docker doesn't expect you to repair it. You simply create another container from the original Image.
Since the Image never changed, the new Container behaves exactly like the previous one. This idea of treating containers as disposable is one of the biggest mindsets shifts Docker introduces. Instead of fixing running environments, you recreate them.

It's faster, cleaner and far more predictable.
Developer Tip: If there's one thing to remember from this section, let it be this:

Images are packages. Containers are running applications.
Docker never runs an Image directly; it always creates a Container from it.

Why Understanding These Concepts Matters Before Writing Your First Command
You may have noticed that we still haven't written a single Docker command and that's by design.
Learning Docker isn't about memorizing commands; it's about understanding what's happening every time you run one.
Once you understand how the Docker Client, Docker Engine, Docker Hub, Images, and Containers work together, Docker stops feeling complicated. The commands become logical because you know what's happening behind the scenes.

That's the purpose of this series: not just to teach you how to use Docker, but to help you understand why it works the way it does.
Now that we've built that foundation, it's time to put it into practice. In the next part, we'll build our first Docker Image and learn how a Dockerfile brings everything together.
.

What Is Lua AI? A Simple Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:55:51 +0000

Ladipo Samuel

Jul 1

What Is Lua AI? A Developer's Guide to Building AI Agents

#agents #ai #llm #programming

3 min read

A Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:54:27 +0000

Ladipo Samuel

Jul 1

What Is Lua AI? A Developer's Guide to Building AI Agents

#agents #ai #llm #programming

3 min read

What Is Lua AI? A Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:54:04 +0000

There's no shortage of AI frameworks today. Every week, a new one promises to make building AI agents easier, so it's easy to dismiss another platform without looking into it. I thought the same until I spent some time going through Lua's documentation.

What stood out to me wasn't that Lua helps you build AI applications; a lot of tools already do that. It's where it tries to reduce the complexity.

When most developers think about building an AI agent, they immediately think about choosing an LLM, writing prompts, connecting APIs, managing conversations, handling tool calls, deploying the application, and making everything work together reliably. Before long, you realize you're spending more time building the infrastructure around the agent than the actual solution you're trying to create.

Lua takes a different approach. Instead of asking you to build all of that yourself, it lets you focus on the part that actually matters: the logic behind your application.

Imagine you're building a customer support assistant for your product. The AI shouldn't just answer questions; it should also be able to check an order, reset a password, create a support ticket, or fetch account information. Traditionally, you'd spend a good amount of time wiring all these pieces together. With Lua, you simply expose those capabilities as TypeScript functions, and the agent can intelligently decide when to use them. You're writing code you already know how to write, while Lua handles much of the AI orchestration behind the scenes.

As I explored further, I realized that the platform is built around just a few concepts, and once those click, everything else starts making sense.

The Agent is exactly what it sounds like: the brain of your application. It's where you define how your AI behaves, what it should know, and which capabilities it has access to.

Then there are Skills. I like to think of these as departments in a company. If your agent works for an e-commerce business, you might have one skill for customer support, another for payments, and another for inventory. Each skill groups together the tools related to that specific responsibility, making your agent easier to organize as it grows.

Inside every skill are Tools. These are simply TypeScript functions that perform real work. A tool might send an email, call your backend API, query a database, process a payment, or retrieve user information. If you've built APIs before, writing tools will probably feel very familiar because you're just writing functions that solve real problems.

Lua also supports webhooks and scheduled jobs, which means your agent doesn't only respond when someone sends it a message. It can react to external events, like a successful payment or a GitHub webhook, or even perform scheduled tasks automatically, such as sending reminders or generating daily reports.

One thing I genuinely appreciate is that Lua doesn't try to replace your existing backend. If you've already invested time building APIs or services, you don't have to throw them away. Your agent simply sits on top of what you've already built, giving users a more natural way to interact with your application.

Getting started is also surprisingly straightforward. You install the CLI, authenticate, create a project, define your agent, build your tools, test everything locally using the built-in chat environment, and deploy when you're ready. The workflow feels familiar, especially if you're already comfortable working with TypeScript projects.

The more I explored Lua, the more I realized that it's less about making AI "smarter" and more about making developers more productive. Instead of spending hours connecting different services and managing the plumbing around an AI application, you can spend that time building features users actually care about.

That's probably my biggest takeaway. Good developer tools don't just help you write code faster; they remove unnecessary complexity so you can focus on solving real problems. From what I've seen so far, that's exactly the direction Lua is trying to take.

I'm still exploring the platform, but if you're interested in building AI agents that can do more than answer questions, Lua is definitely worth checking out. I'm looking forward to building with it and sharing what I learn along the way.

if you want to understand docker, you should check this out

Ladipo Samuel — Mon, 29 Jun 2026 16:36:59 +0000

Ladipo Samuel

Jun 29

Docker Explained (Part 1): Understanding Docker Before Writing Your First Command

#beginners #docker #softwareengineering #tutorial

4 min read

if you want to understand docker and also want to follow along, you should check this out

Ladipo Samuel — Mon, 29 Jun 2026 16:24:37 +0000

Ladipo Samuel

Jun 29

Docker Explained (Part 1): Understanding Docker Before Writing Your First Command

#beginners #docker #softwareengineering #tutorial

4 min read

Docker Explained (Part 1): Understanding Docker Before Writing Your First Command

Ladipo Samuel — Mon, 29 Jun 2026 16:16:40 +0000

Most Docker tutorials start by asking you to install Docker and run your first container. I don't think that's the best way to learn.

If you've ever tried learning a new technology, you've probably experienced this before. You copy commands from a tutorial, everything works, but if someone asks you why it works, you're stuck. You know the syntax, but you don't understand the concept.

Docker deserves better than that.

Before writing a single command, it's important to understand the problem Docker was built to solve. Once you understand the problem, every Docker command starts making sense.

Why Docker Changed Software Engineering

Software engineering has always been about solving problems, but one problem managed to frustrate developers for years.

Imagine you spend days building an application. You install all the required libraries, configure your environment, fix dependency issues, and finally everything works perfectly. You push your code to GitHub, feeling accomplished.

A few minutes later, your teammate clones the project.

They install the dependencies.
Run the exact same command.
And everything breaks.

At first, you think they made a mistake. Then another teammate tries. Same result!!!!

Eventually someone says the sentence almost every developer has heard at least once:

"It works on my machine."

That sentence became a running joke in software engineering, but behind the joke was a real problem.

Every developer's computer is different; one person uses Windows; another uses macOS; someone else develops on Linux; one developer has Python 3.12 installed; another still has Python 3.10; someone upgraded Node.js yesterday; sllomeone else forgot to install PostgreSQL entirely.

Even when everyone follows the same documentation, tiny differences between machines can produce completely different results. The application itself isn't always the problem—the environment is.

As projects became larger and teams became more distributed, this problem became even more expensive. Developers spent hours debugging issues that had nothing to do with their code. Deployments became unpredictable, onboarding new engineers took longer, and production environments often behaved differently from development machines.

Docker didn't just introduce another development tool.

It introduced consistency.

Instead of asking every developer to manually recreate the same environment, Docker packages everything an application needs to run into a portable, isolated environment. Whether it's running on your laptop, your teammate's computer, a CI pipeline, or a production server, the application behaves exactly the same.

That simple idea changed how modern software is built, tested, deployed, and maintained.

What Docker Actually Is?

You'll often hear Docker described as "a containerization platform."

That's technically correct.

It's also not particularly helpful if you're learning Docker for the first time.

Here's a much simpler way to think about it.

Imagine you're speaking at a conference.

Instead of carrying your script in one place, your slides somewhere else, your notes in another folder, and your examples on a flash drive, you put everything into one notebook.

Wherever you go, everything you need goes with you.

Docker does something very similar.

It packages your application together with everything it needs to run.

That includes:

Your application code
The runtime (like Node.js or Python)
Libraries and dependencies
Environment configuration
System packages required by the application

Instead of depending on whatever already exists on another computer, Docker brings its own environment along.

That's why the same application behaves consistently whether it's running on your machine, your teammate's laptop, or a production server.

Docker isn't replacing your application.

It's making sure your application always has everything it needs to run successfully.

Containers Explained Properly

The word container is probably the first Docker term you'll hear, and it's also one of the most misunderstood. Many tutorials describe a container as "a lightweight virtual machine."

While that comparison helps initially, it's not actually what a container is. A container is simply an isolated environment where your application runs.

Think of it as giving your application its own workspace.

Inside that workspace are all the tools your application needs, but it's isolated from other applications running on the same computer.

That isolation is important.

If one application requires Python 3.12 and another still depends on Python 3.10, they can both run on the same machine without interfering with each other because each container carries its own environment.

Containers are also designed to be temporary. You don't usually modify a running container forever. Instead, if your application changes, you create a new container from an updated image. This makes deployments predictable because every new container starts from the same clean state.

This idea of treating containers as disposable is one of the biggest mindset shifts Docker introduces.

Docker vs Virtual Machines

One of the first comparisons people make is between Docker and Virtual Machines. They solve similar problems, but they solve them very differently.

A Virtual Machine creates an entirely new computer inside your computer.
It includes its own operating system, its own kernel, its own system resources, and everything required to behave like a completely separate machine.

That makes Virtual Machines incredibly powerful, but also heavier. They consume more storage, take longer to start, and require more system resources.

Docker containers take a different approach.

Instead of creating a completely new operating system, containers share the host operating system's kernel while keeping applications isolated from one another.

The result is a much lighter environment that starts in seconds, uses fewer resources, and is easier to distribute.

A simple way to picture it is this:

A Virtual Machine is like building a completely separate house on its own piece of land.
A Docker Container is like living in your own apartment inside a modern building. You have your own private space, but some infrastructure is shared, making it far more efficient.

That's one of the reasons Docker became so popular. Developers could run multiple isolated applications on the same machine without the overhead of multiple operating systems.

At this point, you should understand why Docker exists, what problem it solves, what a container really is, and why containers became the preferred approach over traditional Virtual Machines.

In Part 2, we'll go one level deeper by exploring Docker's architecture, understanding Images and Containers in depth, and explaining one of the concepts that confuses almost every beginner: what's the real difference between a Docker Image and a Docker Container?