Most “free tool” sites are either ad-riddled, broken on large files, or gate basic features behind a signup. I spent way too long cycling through them before landing on one that actually works for my day-to-day.
Everything below is from ToolsUp.net — a browser-based toolkit I keep open in a pinned tab. No account, no upload limits, nothing installed.
Here’s what I actually reach for and when.
(toolsup.net)

1. Image Converter — WebP conversion that handles real files
   If you’re building for the web in 2026 and still serving JPEGs everywhere, PageSpeed is telling you about it.
   The Image Converter on ToolsUp handles JPG, PNG, and WebP conversions in-browser. What I care about: it works on large files without timing out, supports bulk conversion when I have a full asset folder to process, and nothing gets uploaded to a server. Everything runs locally in the tab.
   I use this before almost every client handoff that involves images.

2. Screenshot Beautifier — For sharing work that actually looks good
   When I’m dropping a screenshot into a Slack message, a proposal, or a dev.to post, the raw screenshot looks sloppy next to anything professionally designed.
   The Screenshot Beautifier adds background gradients, padding, and device frames around your screenshot. Takes 10 seconds. The result looks like you opened Figma and spent 20 minutes on it.
   Devs share screenshots constantly — PRs, demos, bug reports, portfolio pieces. This is worth bookmarking just for that.

3. JSON Formatter — Validate and read API responses like a human
   You get a raw JSON blob back from an API, it’s minified, and you need to figure out the structure fast. The JSON Formatter validates, formats, and beautifies it instantly in the browser.
   Yes, your IDE does this. But when I’m not in my IDE — reviewing something in a browser tab, debugging a webhook, checking a log — having this in a pinned tab is faster than context-switching.

4. GitHub Profile Generator — Build a README that doesn’t embarrass you
   The GitHub Profile Generator gives you a visual editor for building your README.md. You pick sections, fill in your info, and get clean Markdown output to paste directly.
   If your GitHub profile is still blank or has a four-line placeholder you wrote two years ago, fix it. Recruiters and clients look at it.

5. Password Generator — Custom, strong, done
   I generate passwords for client staging environments, database users, API keys, and test accounts constantly. The Password Generator lets me control length and character sets and generates them client-side — nothing goes over the network.
   It’s a small thing but using a proper generator instead of typing ClientName2024! is a habit worth having.

6. Lorem Ipsum Generator — Placeholder text without leaving the browser
   Designing a layout, building a component, writing a demo — you need filler text. The Lorem Ipsum Generator spits out as many paragraphs, sentences, or words as you need in one click.
   Not glamorous. You’ll use it more than you think.

7. SQL Formatter — Readable queries, fast
   A complex raw SQL query with no indentation is genuinely hard to read. The SQL Formatter takes a dense query and formats it cleanly — useful when debugging slow queries, reviewing migrations, or just trying to understand what a piece of legacy code is actually doing.

8. Base64 Converter + URL Encoder — The ones you always Google
   You need to encode something for a data URI, decode a token, or fix a broken URL with special characters. Instead of Googling “base64 decode online” and landing on some sketchy ad-farm site, just use:

Base64 Converter — encode/decode in-browser
URL Encoder/Decoder — handle special characters without guessing

These are the tools you search for 3 times a week and never remember to bookmark. Consider this your reminder.

Why one site instead of eight tabs
The honest reason I stuck with ToolsUp: I got tired of maintaining a graveyard of single-purpose bookmarks. Half of them go down, get paywalled, or start nagging you to “create a free account to continue.”
ToolsUp has enough coverage that I can handle most one-off tasks without hunting for a new tool. Image work, developer utilities, text tools, PDF stuff — it’s all there, it runs fast, and nothing asks for my email.
If you haven’t checked it in a while, it’s grown a lot — there’s also an AI Image Detector, Background Remover, Color Picker, and a bunch of social media formatters I use less but are solid.
🔗 toolsup.net

What tools are missing from your workflow that you wish existed as a browser-based no-login version? Drop it in the comments.

The first time you look at Claude Code closely, it can feel like a box full of parts that all seem important, but not obviously related.

You see CLAUDE.md. Then rules. Then skills. Then hooks. Then subagents. Then MCP servers. Then… the list goes on. Then context management, planning before coding, verifying outputs, and avoiding letting the session turn into a mess. At first glance, it is easy to think: why are there so many pieces just to get an AI coding workflow working well?

But after spending some time with these concepts, I think the answer is actually pretty simple.

Claude Code is not one thing. It is a small operating system for AI-assisted development.

And like any good system, different parts exist for different jobs.

Start here. Claude Code needs memory, structure, and reach

A good mental model is this:

1. CLAUDE.md and rules shape behaviour.
2. Skills package reusable know-how.
3. Hooks enforce automatic actions.
4. Subagents isolate work.
5. MCP servers connect Claude to the outside world.

That is the big picture (mainly, because there is more to it, but this is enough to get us started).

Once you see it that way, the moving parts stop feeling random. They start feeling like layers. The interesting part is not learning each feature in isolation, but understanding what problem each one solves, and what happens when you try to use the wrong one for that problem. Anthropic’s docs make that distinction pretty clear. CLAUDE.md gives persistent instructions, rules can scope those instructions more precisely, skills extend Claude with reusable playbooks, hooks provide deterministic automation, subagents work in separate contexts with their own tools and prompts, and MCP is the bridge to external tools, data sources, and APIs.

CLAUDE.md and rules. The behavioural layer

If I had to pick the first thing to set up in Claude Code, it would be this.

CLAUDE.md is where you put persistent instructions that Claude should carry into every session for a project, for your personal workflow, or even across an organisation. The docs describe it as plain markdown that Claude reads at the start of every session. They also make an important point that is easy to miss: these instructions are context, not hard enforcement. So if the file is vague, bloated, or contradictory, performance drops. Anthropic recommends keeping it specific, concise, and well-structured, with a rough target of under 200 lines per file.

That last bit matters more than it seems.

A lot of people treat instruction files like a dumping ground. They keep adding preferences, workflows, architecture notes, testing conventions, edge cases, and random reminders until the thing becomes unreadable. Then they wonder why the agent follows it inconsistently. The problem is not that the model is “bad at instructions.” The problem is that the instruction layer is carrying too much weight.

That is where rules come in.

For larger projects, Anthropic recommends organising instructions inside .claude/rules/, and those rules can even be path-specific so they only load when Claude is working in matching areas of the codebase. That means you do not need every frontend rule, testing rule, security note, and data migration convention loaded all the time. You can scope them. In other words, CLAUDE.md should define the broad operating principles of the project, while rules help keep that guidance modular and targeted.

So, if you want one simple distinction:

Use CLAUDE.md for shared default behaviour. Use rules when the project is getting too big for one instruction file to stay sharp.

Skills. The reusable playbook layer

This is where Claude Code starts getting interesting.

A skill is not just “more instructions.” A skill is a packaged capability. Anthropic defines skills around a SKILL.md file. Claude can load a skill automatically when it is relevant, or you can invoke it directly with a slash command (/) based on the skill name (/my_skill). Skills can also include frontmatter, supporting files, argument handling, restricted tool access, and even subagent execution.

That changes the way you should think about them.

A rule says, “here is how we do things around here.”

A skill says, “when this kind of task appears, here is the exact playbook to follow.”

That is a huge difference.

For example, suppose your team has a repeatable workflow for debugging flaky tests, preparing release notes, reviewing API design, or migrating components from one pattern to another. You could try to cram that into CLAUDE.md, but then every session pays the context cost whether that workflow is relevant or not. Skills solve that by staying optional and task-focused. Anthropic explicitly positions them that way in the docs and even notes that for task-specific instructions that do not need to live in context all the time, skills are the better fit.

This is one of those places where the abstraction really clicks.

A good Claude Code setup is not just about telling the model how your codebase works, but about identifying which workflows deserve to become first-class tools.

That is what skills are.

Hooks. The enforcement layer

If CLAUDE.md and skills are about guidance, hooks are about guarantees.

Anthropic describes hooks as user-defined shell commands that run at specific points in Claude Code’s lifecycle. Their wording is important here: hooks provide deterministic control. In other words, they are for the things that must happen, every time, without relying on the model to remember or choose correctly. The best practices guide reinforces the same distinction: unlike CLAUDE.md, which is advisory, hooks are deterministic and guarantee the action happens.

That makes hooks the right tool for a very specific category of problems:

• Run formatting after edits.
• Block writes to protected files.
• Send a notification when Claude needs input.
• Reinject context after compaction.
• Audit configuration changes.

Hooks are workflow mechanics. If you try to solve these mechanics with prompts alone, you are basically hoping the model behaves. Hooks exist so you do not need hope.

This is also where a lot of AI workflows quietly become trustworthy. Not because the model got smarter, but because some parts of the workflow stopped depending on the model entirely.

That is a pattern worth paying attention to.

The more a task sounds like “always do X when Y happens,” the more likely it belongs in a hook, not in a prompt.

Subagents. The isolation layer

Subagents are one of the clearest signs that Claude Code is built for agentic work, not just chat.

Anthropic describes subagents as specialised AI assistants that run in their own context window, with their own system prompt, tool access, and permissions. Claude can delegate work to them when a task matches the subagent’s description, and the subagent works independently before returning the result. The docs also point out why this matters: subagents preserve context, enforce constraints, specialise behaviour, and can route work to different models.

In long coding sessions, context gets polluted fast. Research, false starts, logs, file reads, debugging dead ends, and exploratory thoughts all pile into the same conversation. Anthropic’s best practices page repeatedly emphasises that context is the most important resource to manage, because performance degrades as the context window fills.

Subagents are how you stop every task from becoming everyone’s problem:

• Need a security pass across many files? Use a security reviewer subagent.
• Need research on a subsystem before implementation? Delegate it.
• Need a focused investigation that should not clutter the main thread? Subagent.

I think this is one of the most underrated shifts in AI coding workflows. The question is no longer just “what should the model do?” It is also “which context should do it?”

That is a different level of workflow design.

MCP servers. The reach layer

Without MCP, Claude Code is mostly limited to the local environment and whatever tools it already has access to. With MCP, it can reach out.

Anthropic describes MCP, the Model Context Protocol, as an open standard that lets Claude Code connect to external tools and data sources through MCP servers. Their examples include issue trackers, monitoring platforms, databases, design tools, and workflow automation systems. They also note an important security warning: third-party MCP servers are not universally verified, and untrusted servers can introduce prompt injection or other risks.

This is where Claude Code stops being “an assistant in my repo” and starts becoming “an agent in my workflow.” That sounds exciting, and it is. But it also changes the stakes.

Once Claude can read tickets, inspect production signals, query a database, read Figma, or draft emails, the design problem becomes larger than coding. You are now designing an operational system. Permissions matter. Trust boundaries matter. Server choice matters. Tool access matters.

So while MCP is easily the most expansive capability in the stack, it is also the one that benefits most from restraint.

Just because Claude can connect to everything does not mean it should.

How these parts fit together in practice

Here is the cleanest way I can describe the whole stack:

• CLAUDE.md tells Claude how to behave by default.
• Rules narrow that guidance by topic or path.
• Skills package repeatable expertise or workflows.
• Hooks automate mandatory actions.
• Subagents keep big or noisy tasks isolated.
• MCP servers connect Claude to outside systems.

A practical workflow might look like this:

Your CLAUDE.md defines coding standards, project conventions, and preferred commands. A rule file adds stricter guidance for the /api directory. A skill gives Claude your internal release checklist. A hook runs linting after edits and blocks writes to a protected migration folder. A subagent handles security review in its own context. MCP connects Claude to GitHub, Jira, Sentry, and your database.

At that point, Claude Code is no longer just reacting to prompts, but operating inside a designed environment. And I think that is the real lesson here.

The quality of the workflow does not come from one magical feature. It comes from putting the right responsibility in the right layer.

Best practices that actually matter

Anthropic’s best practices page covers a lot, but a few ideas stand out because they connect directly to all the moving parts above.

First, give Claude a way to verify its work. Tests, screenshots, and expected outputs dramatically improve results because Claude can check itself instead of making you the only feedback loop.

Second, explore first, then plan, then code. Anthropic recommends separating research and planning from implementation, especially for tasks that touch multiple files or unfamiliar areas. That maps nicely to plan mode, but also to skills and subagents when you want a more structured workflow.

Third, provide specific context. Reference files, constraints, patterns, and symptoms. Claude can infer a lot, but it cannot read your mind (yet 😅).

And finally, manage context aggressively. Use /clear between unrelated tasks and avoid stuffing persistent instructions with everything under the sun.

Most of Claude Code’s “moving parts” are really context management tools in disguise.

Closing thoughts

When people first look at Claude Code, they often ask which feature matters most. I think that is the wrong question.

The better question is: what kind of problem am I trying to solve?

• If the problem is persistent guidance, reach for CLAUDE.md and rules.
• If the problem is reusable know how, reach for skills.
• If the problem is guaranteed automation, reach for hooks.
• If the problem is isolation and focus, reach for subagents.
• If the problem is external connectivity, reach for MCP.

That is when the system starts making sense.

Claude Code does not become powerful because it has many parts. It becomes powerful when each part has a clear job. And honestly, that is probably the deeper pattern behind good AI workflows in general. Not more prompts. Not more cleverness. Better boundaries.

Practical takeaway:

• Start with a small, sharp CLAUDE.md
• Add rules only when the project needs more structure
• Turn repeated workflows into skills
• Use hooks for anything that must happen every time
• Use subagents to protect context
• Add MCP carefully, with trust and permissions in mind

Which part of Claude Code feels most useful to you right now: rules, skills, hooks, subagents, or MCP servers, and why?

Toast notifications are often implemented as simple UI feedback components, but making them accessible requires additional considerations. In this implementation, the focus was not just on functionality but also on ensuring the component works well for screen reader users, keyboard users, and assistive technologies.

Accessibility Goals

The toast system was designed with the following accessibility goals:

• Notifications should be announced to screen readers
• Users should have enough time to read the message
• Keyboard users should get the same behavior as mouse users
• Users should be able to manually dismiss notifications

Screen Reader Announcements

To make sure assistive technologies announce notifications automatically, the toast container is implemented as a live region.

This tells screen readers:

• role=”status” → This region contains status updates.
• aria-live=”polite” → Announce updates when the user is idle.
• aria-atomic=”true” → Read the entire notification message.

When a new toast is added, screen readers automatically announce the message without interrupting the user’s current task.

Pause on Interaction

Auto-dismissing notifications can be problematic if users don’t have enough time to read them. To address this, the toast timer pauses when the user interacts with the notification.

onMouseEnter → pause timer
onMouseLeave → resume timer
onFocus → pause timer
onBlur → resume timer

Supporting both hover and focus ensures the behavior works for:

• Mouse users
• Keyboard users navigating with the tab key

Accessible Dismiss Button

Each toast includes a dismiss button so users can remove notifications manually.

X

The aria-label ensures screen readers clearly communicate the purpose of the button, even though the visible content is just an “X”.

Non-Disruptive Notifications

Another important accessibility consideration is not stealing focus when a toast appears.

This implementation ensures that:

• Notifications appear visually
• Screen readers announce them
• The user’s current focus remains unchanged

This prevents interruptions while users are typing or navigating through the interface.

Supporting Multiple Notifications

The system also supports stacked toasts, allowing multiple notifications to appear without overlapping content. A maximum limit prevents excessive notifications from overwhelming users.

Why Accessibility Matters Here

Toast notifications may seem small, but poorly implemented ones can create problems for assistive technology users. By incorporating:

ARIA live regions
keyboard interaction support
pause-on-interaction behavior
accessible controls

the component ensures notifications remain usable and understandable for all users.

Accessibility often comes down to small decisions in implementation, and even simple components like toast notifications can benefit from thoughtful design.

If anyone asks how to build with ADHD, the answer isn’t “overcome it.” It’s “let it generate.”

I have ADHD. I work as a fiber technician during the day. At night I build on a single RTX 4070 laptop. I’ve created 48 tools in 3 months — not because I planned to, but because every context switch created a new tool.

The Pattern

Every time I lost focus on Task A, I’d start Task B. Task B would need a tool that didn’t exist. So I’d build the tool (Task C). By the time the tool was done, I’d forgotten about A entirely — but I had a working tool and a new thread to follow.

After 3 months, those “failures to focus” had produced:

• A local AI mesh running 13 agents on one machine
• An autonomous content engine
• A complete distributed system architecture
• 19 products on Gumroad

The Insight

The “disorder” was the architecture all along.

ADHD doesn’t lose threads. It weaves them in parallel. The trick is building systems that catch what your brain drops — so nothing is lost, just deferred.

My system: the machine remembers so I don’t have to. Every context switch gets logged. Every abandoned thread becomes a seed file. When I circle back (and I always circle back), the context is waiting.

The Breadcrumb Method

The single technique that changed everything:

When you leave a task, write 2 sentences about where you are.

Not a full status report. Just: “I was doing X. Next step is Y.”

That’s it. A git commit message for your brain. It saves ~2 hours/day of re-orientation time because you’re not starting from zero every time you return.

The Fiction Layer

I turned this philosophy into fiction. When the Mountain Sings in Water is Afro-SolPunk about a community that discovers their ancestral water management practices encode mathematical protocols more efficient than anything modern engineering produced.

The metaphor is the same: the “old way” (the way your brain already works) is the advanced architecture. You just need to stop fighting it and start building infrastructure around it.

$0.99 on Gumroad if you want the story: When the Mountain Sings in Water

But the real output isn’t the fiction — it’s the system. Build the machine that remembers. Let the ADHD brain do what it does. Catch everything it drops.

The “broken” way your brain works is the architecture. Build around it.

Building in the dark? You’re not alone. I’m at $0 revenue with 19 products and realized I was overbuilding and underreaching. So instead of building product #20, I’m reaching out. This is that reach.

⚡ Git Commands Workflow

When I started using Git, I tried to learn as many commands as possible.

But over time, I realized something:

You don’t need to know everything.
You need to master the workflow.

Most of my day-to-day work revolves around a small set of commands—used repeatedly in different contexts.

🧠 The Real Git Workflow

At a high level, Git revolves around three stages:

• Working directory → where you make changes
• Staging area → where you prepare changes
• Repository → where changes are committed

Understanding this flow matters more than memorizing commands.

🔄 1. Starting Work

git pull
git checkout -b feature/my-feature

What this does:

• Sync latest code
• Create a new branch

👉 This is usually how I start my day.

✍️ 2. Making Changes

git status
git add .

• git status → shows what changed
• git add → stages changes for commit

👉 I check the status a lot more than I expected.

💾 3. Saving Work

git commit -m "Add feature X"

• Creates a snapshot of your changes
• Helps track history over time

👉 Good commit messages matter more than the command itself.

🚀 4. Syncing with Remote

git push
git pull

• push → sends your changes
• pull → brings latest updates

👉 This is where most conflicts show up.

🌿 5. Working with Branches

git branch
git checkout main
git merge feature/my-feature

• Branching helps isolate work
• Merging brings changes together

👉 Simple concept—but causes most real-world issues.

🧰 6. Commands I Started Using Later

These didn’t make sense early on—but became useful over time:

git stash
git log
git diff

• stash → save work temporarily
• log → view history
• diff → see changes

👉 These are workflow boosters, not essentials.

⚠️ What Actually Matters (Not the Commands)

Over time, I realized:

• Git problems are rarely about commands
• They’re about understanding state and flow

Most issues come from:

• Not knowing what’s staged
• Working on the wrong branch
• Pulling at the wrong time

🧠 What I’d Do Differently

If I were starting again:

• Focus on workflow, not commands
• Learn:
  • status
  • add
  • commit
  • branch
  • merge

👉 That’s enough for most real work.

⚡ Practical Takeaways

• You don’t need 50 Git commands
• Master the core workflow first
• Use advanced commands only when needed

🏁 Final Thought

Git feels complex when you try to learn everything.

It becomes simple when you think in terms of:
“Where are my changes right now?”

If you have reached here, then I have made a satisfactory effort to keep you reading. Please be kind enough to leave any comments or share any corrections.

My Other Blogs:

• Shift-Left Performance Testing in Spring Boot: Engineering Stability Before Scale
• Practical Tips When Working with AI Coding Assistants
• To Avoid Performance Impact Never Use Spring RestClient Default Implementation in Production
• Modern DevSecOps Needs More Than One Tool: A Practical Secure SDLC Strategy
• ⁠Supercharge Your E2E Tests with Playwright and Cucumber Integration
• When Resilience Backfires: Retry and Circuit Breaker in Spring Boot
• Setup GraphQL Mock Server
• Cracking Software Engineering Interviews

Hey IH! I’m Ali, a solo developer, and I just finished building CryptVault — an end-to-end encrypted secrets manager where no one (not even me) can access your data.

Why I built this

I’ve been using password managers for years, but something always bothered me:

• Most popular ones had data breaches (LastPass, anyone?)
• The “trust us, your data is safe” model felt wrong
• Affordable options were either too basic or not truly encrypted
• None of them let me control where my encrypted data is stored

So I decided to build one myself — with zero-knowledge architecture from day one. The server never sees your plaintext data. Period.

The tech behind it

This was the most fun (and challenging) part:

• RSA-4096 for key wrapping — each user gets a unique keypair
• AES-256-GCM for encrypting actual secrets — fast and authenticated
• Argon2id for key derivation from your Master Password — resistant to GPU/ASIC attacks
• Two-layer authentication: Account login (email + password → JWT) and Vault unlock (Master Password → decrypts your private key in memory)

Your Master Password never leaves your device. It derives the key that decrypts your RSA private key, which then decrypts your secrets. If you forget it, even I can’t help you — that’s the point.

For recovery, I implemented a 13-word BIP-39 mnemonic (similar to crypto wallets). You get it once when you create your vault.

What it does

• Store passwords, API keys, SSH keys, notes, cards, emails
• Built-in TOTP Authenticator — no separate 2FA app needed
• Password Health Analysis — flags weak, reused, and aging passwords
• Dark Web Monitoring — alerts when your credentials appear in breaches
• Bring-Your-Own-Storage (BYOS) — connect your Google Drive for encrypted backups you control
• Full English + Arabic support with RTL layout

Stack

• Frontend: React 19 + Vite 7 + Tailwind CSS
• Backend: Express 5 + Prisma 7 + PostgreSQL
• Deployment: Docker on a VPS, Cloudflare for DNS/CDN
• Payments: Stripe Billing

Business model

Simple and transparent:

• Free: 20 secrets, 5 categories, built-in TOTP
• PRO: $1.99/mo — unlimited secrets, dark web monitoring, BYOS, export/import

I wanted PRO to be affordable enough that it’s a no-brainer if you use the free tier and want more.

Challenges I faced

1. Encryption complexity: Getting RSA + AES + Argon2id to work together seamlessly across client and server took weeks of iteration. Key management is hard.

2. Zero-knowledge trade-offs: When you can’t read user data, you can’t offer “forgot password” recovery the normal way. The BIP-39 recovery key was my solution.

3. Solo developer bandwidth: Building frontend, backend, encryption layer, admin panel, payment integration, and landing page alone is… a lot. But also incredibly rewarding.

What’s next

Launching on Product Hunt on March 31 (Tuesday). After that:

• Browser extension for auto-fill
• Mobile app
• More BYOS providers (Dropbox, OneDrive)
• Team/organization vaults
• Self-hosted option

Try it out

The app is live at cryptvault.app. Free tier available — no credit card required.

I’d love to hear your thoughts, feedback, or questions about the architecture. Happy to go deep on the encryption design if anyone’s curious!

Build a Data Science Query Language in Python using Lark

What if you could write something like this:

DATA [1, 2, 3, 4, 5]
SUM
MEAN
STD

…and have it behave like a mini data science engine?

In this tutorial, we’ll build a **Domain-Specific Language (DSL)** for data analysis using:

- Python   
- Lark (parser library)   
- NumPy   

---

#  What Are We Building?

We are creating a **custom query language** that:

- Accepts a dataset
- Runs statistical commands
- Prints results

---

#  Step 1: Install Dependencies

```
{% endraw %}
bash
pip install lark numpy
{% raw %}

Step 2: Define the Grammar

The grammar defines how our language looks.

python
from lark import Lark, Transformer
import numpy as np

grammar = """
start: data command+

data: "DATA" list

command: "SUM" -> sum
       | "MEAN" -> mean
       | "STD" -> std
       | "MAX" -> max
       | "MIN" -> min

list: "[" NUMBER ("," NUMBER)* "]"

%import common.NUMBER
%import common.WS
%ignore WS
"""

Explanation

start: data command+

• Program must start with DATA
• Followed by one or more commands

data: "DATA" list

• Defines dataset input
• Example:

plaintext
  DATA [1, 2, 3]

Commands

plaintext
SUM → sum
MEAN → mean
STD → std
MAX → max
MIN → min

• These map text → function names
• -> sum means call sum() in Transformer

List Rule

plaintext
list: "[" NUMBER ("," NUMBER)* "]"

• Accepts:

  • [1]
  • [1, 2, 3]

• (, NUMBER)* means repeat

Ignore Spaces

plaintext
%ignore WS

• Allows flexible formatting

⚙️ Step 3: Build the Interpreter

Now we convert parsed text into execution.

python
class DLangInterpreter(Transformer):

    def data(self, items):
        self.data = np.array([float(x) for x in items[0]])
        return self.data

Explanation

• items[0] → list of numbers
• Convert to NumPy array
• Store in self.data for reuse

Step 4: Add Operations

SUM

python
def sum(self, _):
    print(np.sum(self.data))

MEAN

python
def mean(self, _):
    print(np.mean(self.data))

STD

python
def std(self, _):
    print(np.std(self.data))

MAX

python
def max(self, _):
    print(np.max(self.data))

MIN

python
def min(self, _):
    print(np.min(self.data))

Explanation

• Each function matches grammar rule
• _ = unused input
• Uses NumPy for computation
• Prints result immediately

Step 5: Parse List

python
def list(self, items):
    return items

Explanation

• Returns list of numbers
• Passed to data() method

Step 6: Create the Parser

python
parser = Lark(grammar, parser="lalr", transformer=DLangInterpreter())

Explanation

• lalr → fast parsing algorithm
• transformer → auto-executes logic

Step 7: Read Input File

python
with open("example.dl") as f:
    code = f.read()

parser.parse(code)

Example example.dl

plaintext
DATA [10, 20, 30, 40]
SUM
MEAN
MAX

✅ Output

plaintext
100
25.0
40

How It Works (Flow)

plaintext
Text Input
   ↓
Parser (Lark)
   ↓
Grammar Rules Match
   ↓
Transformer Methods Trigger
   ↓
NumPy Executes
   ↓
Output Printed

✨ Why This Is Powerful

• You built a mini programming language

• Clean separation of:

  • Syntax (grammar)
  • Execution (Transformer)

• Easily extensible

Next Features You Can Add

1. Filtering

plaintext
FILTER > 10

2. Sorting

plaintext
SORT ASC

3. CSV Support

plaintext
DATA file.csv

4. Chaining

plaintext
DATA [1,2,3,4]
FILTER > 2
MEAN

Final Thought

This is how real systems like:

• SQL
• Pandas query engine
• Spark

…start at a basic level.

You just built the foundation of a data query engine

If You Liked This

Drop a like ❤️
Follow for more AI + Systems content
And try extending this DSL yourself!