DEV Community: Muhammad Iqbal

PromQL Made Easier: Build, Understand, and Debug Prometheus Queries with AabiTech

Muhammad Iqbal — Mon, 02 Nov 2026 15:40:34 +0000

If you work with Prometheus, you probably know that writing PromQL (Prometheus Query Language) can become challenging, especially when dealing with complex aggregations, rate calculations, histogram metrics, label matching, and alerting expressions.

Even experienced developers sometimes need to look up syntax, revisit function documentation, or break down complicated expressions to understand what a query actually does.

To make this workflow easier, I've built a free online PromQL Query Builder & Explainer as part of AabiTech.

🔗 Try it here: https://aabitech.com/tools/promql-query-builder

What Is the PromQL Query Builder?

The PromQL Query Builder & Explainer is a browser-based workspace that helps developers create, understand, and troubleshoot Prometheus queries.

Instead of switching between documentation, editors, and different reference websites, you can perform several common PromQL tasks in one place.

The tool is designed for:

DevOps engineers
Site Reliability Engineers (SREs)
Backend developers
Observability engineers
Kubernetes practitioners
Students learning Prometheus and monitoring

Key Features

1. Visual PromQL Query Builder

Building PromQL expressions manually can be tedious, particularly when combining multiple functions and label matchers.

The visual builder helps you compose queries using:

Metric selectors
Label matchers
Range vectors
Functions
Aggregations

It provides a more approachable way to construct PromQL expressions without having to remember every syntax detail.

2. PromQL Editor with Syntax Support

The integrated editor provides a dedicated environment for writing and editing PromQL expressions.

It includes:

Syntax highlighting
Autocomplete support
Parser diagnostics
Additional rule-based warnings

This makes it easier to identify potential issues while working on queries.

3. PromQL Query Explainer

Ever found a PromQL query in a dashboard or monitoring configuration that you couldn't immediately understand?

Paste the expression into the explainer to get a plain-English breakdown of its components.

It's particularly useful when:

Learning PromQL.
Reviewing queries written by other developers.
Understanding nested functions and aggregations.
Exploring unfamiliar monitoring expressions.

4. Ready-to-Use PromQL Templates

You don't always need to start from scratch.

The tool includes practical query templates covering common monitoring scenarios, including:

HTTP request traffic
HTTP error rates
CPU utilization
Memory usage
Kubernetes monitoring
Latency percentiles
SLO-related metrics

These examples can serve as starting points for building your own queries.

5. Prometheus Alert Rule YAML Generator

Writing alert rules involves more than creating a PromQL expression.

The tool also provides functionality to generate draft Prometheus alert rule YAML for HTTP 5xx error ratios, with configurable settings.

You can use the generated configuration as a starting point for your monitoring setup.

Privacy-Friendly and Browser-Based

One of the design principles behind AabiTech tools is to keep processing in the browser wherever practical.

The PromQL Query Builder is designed to work without requiring:

User registration
A connected Prometheus server
An external AI API
Uploading your queries to a backend for building and explanation

Important: The tool provides local syntax diagnostics and static checks. It does not execute queries against a live Prometheus instance or verify metric availability in your monitoring environment.

Who Can Benefit From It?

For beginners: Learn PromQL concepts and understand how different functions and operators work.

For DevOps engineers: Quickly construct common monitoring expressions and prepare alert-rule configurations.

For SREs: Explore error-rate, latency, and SLO-related queries.

For experienced developers: Save time when writing, reviewing, and troubleshooting PromQL expressions.

Try It Yourself

The tool is completely free to use.

👉 PromQL Query Builder & Explainer

I'd genuinely appreciate feedback from developers who work with Prometheus in real-world environments.

A few questions for the community:

Which PromQL functions or expressions do you find most difficult to work with?
What features would make a PromQL builder more useful in your daily workflow?
Would you find additional Kubernetes and Grafana-focused query templates useful?

I'm building AabiTech to create practical, accessible tools that solve real problems for developers.

If you try it, let me know what you think!

A PromQL Query Builder That Doesn't Need Your Prometheus Server

Muhammad Iqbal — Wed, 28 Oct 2026 14:42:24 +0000

PromQL is one of those languages you only half-remember. You know rate() goes on counters, you think it goes before sum(), and you'll definitely forget the le label the one time it matters.

Most tools that help with PromQL assume you already have a running Prometheus or Grafana connected to real data. That's great for day-to-day work, but not when you're:

learning PromQL for the first time
reviewing a teammate's query in a PR
sketching an alert before the exporter is even deployed
on a locked-down machine with no access to production

So I want to show a different take: the PromQL Query Builder & Explainer from AabiTech.

What makes it different

1. No Prometheus connection required

Everything runs in your browser. The builder, explanations and diagnostics work without a data source, so there's nothing to configure, no credentials to hand over and no signup.

Most query builders pull metric names and labels from a live server. That makes autocomplete accurate, but it also makes them useless without one. This tool takes the opposite trade-off: it's available anywhere, instantly.

2. It explains queries, not just builds them

Paste any expression and the Explain & lint tab gives you a component breakdown: selectors, functions, aggregations and range windows, described in plain English.

This is great for onboarding and code review. Instead of asking "what does this sum by (le, job) do?", you can read it.

3. Built-in pitfall detection

Beyond parser diagnostics, the tool flags common mistakes:

sum() applied before rate() on counters (resets get hidden)
classic histogram queries that may drop the le label
overly broad regex matchers
placeholder or example metric names left in

Take this classic bug:

sum(http_requests_total) / rate(...)   # aggregating before rate

Aggregating counters first hides resets per series. The tool nudges you toward:

sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))

These are advisory heuristics, not guarantees, but they catch the mistakes that waste an afternoon.

4. Four workflows in one workspace

Query builder: structured inputs for metric, label matchers, range function, window and aggregation
Explain & lint: plain-English breakdown plus static diagnostics
Templates: curated patterns for HTTP rates, 5xx ratios, p95 latency, CPU/memory, disk, down targets, Kubernetes restarts and more
Alert rule helper: generates a draft YAML rule for an HTTP 5xx error-ratio alert

5. Honest about its limits

I appreciate that the tool says plainly what it can't do. Parser diagnostics validate syntax only. They can't confirm a metric exists, that the query returns data, or that it's efficient. Templates are starting points, and generated alert YAML is a draft to review.

That honesty matters in monitoring, where a query that "looks right" can silently return nothing.

Quick example: p95 latency

Using the templates, a classic-histogram p95 looks like this:

histogram_quantile(0.95, sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

Drop it into the editor and the explainer walks through each layer. It also reminds you that native histograms work differently.

When to use what

Situation	Best fit
Exploring real metrics and labels	A tool connected to your live data source
Learning, reviewing or drafting queries offline	This builder
Final validation before production	Your own Prometheus, always

They're complementary. Draft and sanity-check here, then validate against real data.

Try it

👉 aabitech.com/tools/promql-query-builder

Free, browser-based, no signup. I'd love to hear which PromQL pitfalls bite you most. Drop them in the comments and I'll check whether the linter catches them.

I Migrated a Bootstrap Page to Tailwind Without Losing My Mind (Here's How)

Muhammad Iqbal — Tue, 27 Oct 2026 16:38:30 +0000

Let me guess how you got here.

You've got a project full of Bootstrap. Somewhere between mb-3 and col-md-6, you decided Tailwind is the future, or your team did, or you just got tired of fighting !important. Now you're staring at 40 HTML files and wondering how long a rewrite will take.

I've been there. The good news is that a lot of the work is mechanical, and mechanical work is exactly what tools are for. In this tutorial I'll walk through the free Bootstrap to Tailwind Converter from AabiTech, show how it works, and be honest about where it stops and you have to take over.

What the tool does

You paste Bootstrap HTML on one side, and it gives you Tailwind HTML on the other. Conversion updates live as you type. A few things I like:

Bootstrap 4 and 5 are both selectable as the source.
Tailwind CSS 3 and 4 are selectable as the target.
It runs in your browser. The page says your HTML is processed locally and isn't uploaded to a conversion endpoint, which is nice if the markup belongs to a client.
It doesn't hide what it can't convert. Classes with no verified mapping stay in the output and get flagged, instead of silently disappearing.

That last point is the most important one. A converter that quietly drops classes will cause bugs you find three weeks later. One that says "I'm not sure about this one" is a colleague I'd trust.

Step 1: Paste a real snippet

Don't start with your whole layout. Pick one small, self-contained chunk, like a card or a hero section. Here's a typical Bootstrap 5 one:

<div class="container">
  <div class="row">
    <div class="col-md-6 mb-3">
      <h2 class="text-center fw-bold mb-4">Hello, world</h2>
      <p class="text-muted">A small card-ish thing.</p>
      <a href="#" class="btn btn-primary">Get started</a>
    </div>
  </div>
</div>

Pick Bootstrap 5 as the source and your Tailwind version as the target. Match the source to what you're actually running. The tool says plainly that the version selector doesn't resolve every version-specific difference.

Step 2: Read the output

The tool's output should look something like this (yours may differ in the details):

<div class="container mx-auto px-4">
  <div class="flex flex-wrap">
    <div class="md:w-1/2 mb-4">
      <h2 class="text-center font-bold mb-6">Hello, world</h2>
      <p class="text-gray-500">A small card-ish thing.</p>
      <a href="#" class="btn btn-primary">Get started</a>
    </div>
  </div>
</div>

Notice what happened:

fw-bold became font-bold, an easy one-to-one swap.
mb-3 became mb-4, and mb-4 became mb-6. That's not a bug. Bootstrap and Tailwind use different spacing scales.
btn btn-primary stayed put. That's the "needs review" bucket.

Step 3: Understand the spacing scale

This is where most people get bitten, so here's the cheat sheet. Bootstrap's spacing steps are based on a 1rem spacer, and Tailwind's are based on 0.25rem units:

Bootstrap	Size	Tailwind (default theme)
`mb-1`	0.25rem	`mb-1`
`mb-2`	0.5rem	`mb-2`
`mb-3`	1rem	`mb-4`
`mb-4`	1.5rem	`mb-6`
`mb-5`	3rem	`mb-12`

So the same-looking class means different things. If you ever "fix" a converted file by hand, remember this table.

Step 4: Check the diagnostics panel

Under the editors, the tool breaks recognized classes into three groups:

Exact mappings: safe, boring, great.
Approximations: close, but verify them visually.
Need review: not converted, left for you.

It also shows an "exact mapping coverage" figure. The page itself warns this is a rule-coverage indicator, not a guarantee that the page will render identically. I'd read it the same way: a rough sense of how much hand-work is left, not a quality score.

Step 5: Use the live preview, but don't trust it blindly

There's a preview with Mobile, Tablet and Desktop toggles. It's handy for a quick sanity check, and it runs in a sandboxed frame. Two caveats:

It loads Tailwind from a CDN, so you need an internet connection.
It uses Tailwind's default theme. If your project has custom colors or breakpoints, the real result can differ.

Treat it as a smoke test, not a sign-off.

The part no converter can do for you

Here's the honest bit. I'd rather you hear it from me than discover it at 11pm before a deploy.

Grid layouts are approximate. Bootstrap's row and col-* classes come with gutters, negative margins and nesting behavior that can't be fully inferred from class names alone. The converter gives you a starting point. Compare the layout side by side.

Components are a different story. btn, card, modal, navbar, dropdowns and accordions rely on Bootstrap's CSS, structure and sometimes JavaScript. There's no single Tailwind utility that replaces them. You'll want to either:

build your own reusable component (a <Button />, or @apply in a stylesheet), or
reach for a Tailwind component library.

Your config matters. The tool doesn't read your tailwind.config.js or your Bootstrap Sass variables. If you customized either, expect to adjust.

It's not a full-document converter. According to the page, scripts, iframes, objects and embeds are removed from the output. Use it for fragments, and move scripts over yourself. It also isn't an HTML sanitizer, so review the markup before putting it into your app.

My suggested workflow

If I were migrating a real project tomorrow, I'd do this:

Convert one component at a time, not whole pages.
Paste, convert, and read the diagnostics first.
Fix the "need review" items by hand, starting with buttons and cards.
Drop the result into the project and look at it in the browser at a few widths.
Commit small. Future-you will thank you when something looks off.

A converter won't finish the migration for you. What it does is remove the tedious 70%, the mb-3 to mb-4 busywork, so you can spend your attention on the parts that need judgment.

Wrapping up

The Bootstrap to Tailwind Converter is free, needs no signup, and is upfront about its limits. That honesty is why I'd use it. Try it on one ugly legacy snippet, check the diagnostics, and see how much time it saves.

Have you migrated from Bootstrap to Tailwind? What was the one thing that tripped you up? I'd love to hear it in the comments.

Happy migrating! 🚀

Generate Pydantic v1/v2 Models from JSON in Seconds (and What to Fix Afterward)

Muhammad Iqbal — Mon, 26 Oct 2026 13:40:34 +0000

Hand-writing Pydantic models from a large JSON payload is mechanical work: map types, nest classes, repeat. I've been using a free JSON to Pydantic Converter from AabiTech to skip that step. Here's what it does and where you still need to think.

What it does

Paste JSON (or upload a file, up to 5 MB) and get Python model code back.

Nested objects become separate models, and arrays of objects become list[Model]
Pydantic v2 or v1 compatibility mode
Configurable root model name
2, 4, or 8 space indentation
Copy to clipboard or download as .py
Runs client-side; the page states your JSON is processed in the browser and generated code is never executed

No signup required.

Example

Input:

{
  "name": "Ayesha",
  "age": 25,
  "active": true
}

Output:

from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int
    active: bool

With nested payloads, you get one class per object, referenced from the parent. That's where it saves the most time.

v1 vs v2: pick the right mode

The two versions differ enough that wrong-version output will bite you:

	Pydantic v1	Pydantic v2
Parse a dict	`Model.parse_obj(d)`	`Model.model_validate(d)`
Serialize	`m.dict()`	`m.model_dump()`
Config	`class Config:`	`model_config = ConfigDict(...)`

Select the mode matching your installed version, then verify imports and config anyway.

What a single sample can't tell you

Generated models are inferred from one example, so review these before shipping:

1. Optional vs nullable. These are different things.

a: str | None            # required, but may be None
b: str | None = None     # may be omitted, may be None

A sample with "b": null doesn't tell you whether b can be absent. Check more records.

2. Mixed types. If a field is int in some records and str in others, you need a union or a validator:

id: int | str

3. Key naming. firstName, user-id, or keys with spaces need Python-safe attribute names plus aliases:

from pydantic import BaseModel, Field

class User(BaseModel):
    first_name: str = Field(alias="firstName")

Check alias and serialization settings (by_alias=True on dump) before wiring this to an external API.

4. Empty arrays. [] gives no item type to infer from. Fill it in manually.

5. Constraints. No sample will tell you about min_length, regex patterns, enums, or ranges. Add them yourself.

Suggested workflow

Validate your JSON first (the site also has a JSON Formatter)
Use a representative sample, ideally the most complete record you have
Generate with the right Pydantic version
Fix optionals, unions, and aliases
Add validators and constraints
Test against both valid and invalid payloads

Plugged into FastAPI, the result gives you request validation and OpenAPI docs almost immediately:

@app.post("/users")
async def create_user(user: User):
    return user

Privacy note

Even though processing happens in the browser, keep tokens, passwords, and real customer data out of sample payloads. Good habit for any online tool.

Try it

aabitech.com/tools/json-to-pydantic-converter

Treat the output as a solid first draft, not a finished schema. How do you handle messy third-party API responses? Share your approach in the comments.

Tutorial: Tune Your RAG Chunking Visually (Free Browser Tool, No Setup)

Muhammad Iqbal — Mon, 19 Oct 2026 15:56:34 +0000

Chunking is the RAG step everyone copies from a tutorial ("size 1000, overlap 200") and never looks at again. In this walkthrough, you'll use a free browser tool to actually see your chunks, compare strategies, estimate costs, and export working splitter code.

What you'll need: a browser and a sample document (Markdown or plain text works best). No install, no signup.

Tool: RAG Chunking Simulator & Visualizer

Per the site, text is processed locally in your browser instead of being sent to a chunking API. For confidential docs, still follow your organization's policies.

What you'll do

Load a document
Compare chunking strategies
Tune size and overlap
Inspect boundaries
Check diagnostics
Try parent-child chunking
Test retrieval with a keyword query
Estimate cost, storage, and context budget
Export code and chunks

Step 1: Load a document

Open the tool. Under Source document, you have three options:

Use a built-in preset: RAG sample, Markdown sample, or Code sample
Paste your own text
Click Import .txt / .md

For this tutorial, start with the Markdown sample so heading-aware strategies have something to work with. A live counter shows characters, words, and estimated tokens as you type.

Step 2: Pick and compare strategies

In Compare chunking strategies, select several at once. The tool supports eight:

Strategy	Best for
Fixed-size	A simple baseline
Recursive character	General text (paragraph → newline → space fallback)
Sentence-aware	Avoiding mid-sentence cuts
Paragraph-aware	Keeping related sentences together
Markdown-aware	Docs with headings and structure
Heading-based	Splitting by section
Regex-based	Custom formats (you supply the pattern)
Word-based	Word-count limits instead of characters

Select Fixed-size, Recursive, and Markdown-aware for now.

The benchmark table then shows, per strategy: chunk count, average size, size variance, overlap characters, and estimated cost. Click any row to make it the active strategy in the visualizer below.

What to look for: two strategies can produce the same chunk count with very different size variance. High variance usually means some chunks are tiny and others are huge.

Step 3: Tune size and overlap

Under Chunk parameters, adjust:

Chunk size
Boundary overlap
Measurement mode: Characters, Words, or Estimated tokens

Pick the unit deliberately. A character limit doesn't guarantee a chunk fits your model's token limit. If you choose estimated tokens, set Chars / token (the token counting mode also offers whitespace and word+punctuation counts).

Try this experiment:

Set overlap to 0 and note the chunk count and overlap chars.
Raise overlap gradually.
Watch the benchmark table: more overlap means more duplicated text, which means more tokens to embed and store.

The goal is the smallest overlap that still keeps context intact across boundaries. There's no universal number, so test on your own documents.

Step 4: Inspect boundaries visually

Scroll to the source boundary map. Alternating colors mark odd and even chunks, and shared overlap regions are highlighted separately.

Then:

Use Prev / Next or the slider to scrub through chunks one at a time
Click a block on the minimap ribbon to jump to that span
Open the chunk preview inspector to read the actual content and its source offsets

Ask yourself at each boundary:

Did a sentence get cut in half?
Is a heading separated from its content?
Is a code block or list broken apart?

If yes, switch strategy or adjust size and re-check.

Step 5: Read the diagnostics

The Chunk-size distribution & diagnostics panel gives you a 6-bucket histogram plus counts for:

Tiny chunks (configurable Tiny threshold)
Oversized chunks
Boundary alerts
Near duplicates

These are review prompts, not a verified quality score. The page itself labels the context-preservation heuristic as "not a validated retrieval-quality score." Use them to know where to look, then judge by reading the chunks.

Step 6: Try parent-child chunking

If small chunks match well but lack context, try Parent-child hierarchy chunking:

Set a Child size (small, for precise matching)
Set a Parent size (larger, for context)
Enter a query to see which child chunks rank and which parent context they map to

This models small-to-large retrieval: match on the child, return the parent. You can export the structure with Export parent-child JSON.

Step 7: Test with the keyword retrieval simulator

In Keyword retrieval simulator, enter a query you expect real users to ask and set Top K.

This is a lexical baseline, not an embedding search, so it won't predict your vector store's results. It's still handy for a quick sanity check: does the chunk that should answer the question rank near the top, or did a boundary scatter the relevant terms?

If your relevant text keeps landing in the wrong chunk, revisit Steps 3 and 4.

Step 8: Estimate cost, storage, and context budget

Three panels help with planning:

Embedding cost. Enter your provider's Price / 1M tok ($) and compare strategies in the benchmark table. Treat it as a relative comparison, not an invoice. Token counts are estimated from a chars-per-token ratio.

Index storage. Set vector dimensions, bytes per dimension (float32 / float16 / int8), and metadata bytes per chunk. The tool reports raw vector payload, metadata payload, and an estimated total. Real vector databases add their own overhead.

Context-window budget. Set a context budget and a reserve for prompt and answer. The tool greedily packs chunks to show how many fit. You can export the selected context.

Step 9: Export code and chunks

Once you've settled on settings, open the Framework configuration generator:

Choose LangChain (Python) or LlamaIndex (Python)
Review the generated code (synced to your current sliders)
Copy code, Download Python example, or Download config

For a recursive strategy, the LangChain output will look something like this (exact output depends on your settings):

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100,
    separators=["\n\n", "\n", " ", ""],
)

chunks = splitter.split_text(text)

To export the chunks themselves, use JSON, JSONL, CSV, or TXT. Before exporting, fill in Chunk attribution metadata (source ID, page, section, plus an optional JSON object) so every record carries its origin.

Heads-up on offsets: they're JavaScript UTF-16 code units, not UTF-8 byte offsets. Convert them if your pipeline expects bytes.

Step 10 (optional): Save and share your experiment

Under Experiment history & state sharing, name and save a snapshot in your browser, or use Copy share settings to generate a URL-hash link. Teammates open it and see your exact configuration.

Limitations to keep in mind

Token counts and costs are estimates. Validate with your embedding model's real tokenizer before production.
The keyword simulator is lexical, not semantic.
Good-looking chunks don't guarantee good answers. Evaluate with real queries and measure retrieval relevance and answer quality in your actual pipeline.

Wrap-up

You've now loaded a document, compared strategies, tuned overlap, inspected boundaries, checked diagnostics, tried parent-child retrieval, estimated costs, and exported working code. Total setup time: zero.

Try it on your own docs: aabitech.com/tools/rag-chunking-simulator

Which strategy and chunk size worked best for your content? Share your findings in the comments. 👇

I Built a Free Tool to Convert SQL to Laravel Migrations

Muhammad Iqbal — Sun, 18 Oct 2026 17:41:08 +0000

If you work with Laravel, you have probably faced this situation at least once.

You get an old database. Maybe it's a .sql file from a client, or a MySQL schema from a previous project. Now you have to bring it into a Laravel app, and Laravel wants migrations.

So you open the SQL file and start writing Schema::create() by hand. Table by table. Column by column. VARCHAR(255) becomes string(), BIGINT UNSIGNED becomes unsignedBigInteger(), and then you do the same for indexes and foreign keys.

It's boring work, and it's easy to make small mistakes. I got tired of it, so I built a tool for it.

Meet the SQL to Laravel Migration Converter

It's a free online tool on AabiTech. You paste your SQL CREATE TABLE statements, and it gives you Laravel migration code.

No signup, no install. You just open it in your browser and use it.

How to use it

Paste your SQL schema, or import a .sql file.
Pick your SQL dialect, or leave it on auto detect.
Choose your Laravel version.
Copy the migration, or download it as a ZIP.

That's it.

A quick example

Say you have this SQL:

CREATE TABLE users (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  email VARCHAR(255) NOT NULL UNIQUE,
  created_at TIMESTAMP NULL,
  updated_at TIMESTAMP NULL
);

You get a Laravel migration with the Schema::create structure, the right column methods, and the unique index. The exact output depends on the options you pick (more on that below).

What I like about it

It works in your browser. Your SQL is parsed and converted locally. It is not sent to my server. This matters because database schemas can be sensitive, and I wouldn't want to paste a client's schema into a random website either.

It supports several SQL dialects. MySQL / MariaDB, PostgreSQL, SQLite, and SQL Server. Or you can let it auto detect.

It supports multiple Laravel versions. You can target Laravel 9, 10, 11, 12, or 13.

You control the output. There are a few options you can change:

Output style: Idiomatic, Explicit, or Compatibility-focused
Naming: keep names as they are, or convert to snake_case or lowercase
Smart Laravel idioms: for example, collapsing created_at and updated_at into timestamps(), and soft deletes into softDeletes()
Separate FK phase: puts foreign keys in their own step, which helps with migration order
Exclude tables: skip tables you don't need

It can generate more than migrations. If you want, it can also create models, factories, and seeders from your INSERT statements.

It gives you a conversion report. You can see how many tables and columns were found, how many were converted, and any warnings. There is also a column mapping table that shows each SQL column next to its Laravel version, so you can check it quickly.

Please review the result

I want to be honest about this: no converter is perfect.

SQL dialects have many database-specific things, like storage engines, collations, generated columns, and special default expressions. Some of these don't map directly to Laravel's Schema Builder.

So treat the output as a strong starting point, not the final answer. Before you use it:

Compare the migration with your original SQL
Check data types, defaults, and nullable columns
Check the order of your migrations, because foreign keys need the referenced table to exist first
Run it on a test database before anything serious

The tool saves you the repetitive typing. You still do the thinking.

Who is it for?

Developers moving a legacy PHP project to Laravel
Anyone given a .sql file and asked to "make it Laravel"
People who want to quickly turn a schema into migrations, models, and factories
Students learning how SQL types map to Laravel's Blueprint

Try it

You can find the tool here:

👉 SQL to Laravel Migration Converter

If you try it and something doesn't convert correctly, or you have an idea for a feature, please tell me in the comments. Real SQL schemas are messy, and feedback from real projects helps me improve it.

I'm also adding more free developer tools to AabiTech, so take a look if you're interested.

Thanks for reading! 🙌

Stop Guessing Your RAG Chunking Strategy. Inspect It

Muhammad Iqbal — Thu, 15 Oct 2026 16:26:28 +0000

If you've built a RAG pipeline, you know chunking isn't just splitting text into smaller pieces.

Chunk size affects context retention. Overlap introduces duplication. Splitting on arbitrary boundaries can separate code, paragraphs, or related ideas. And a configuration that looks reasonable on paper might perform poorly during retrieval.

Usually, figuring this out means tweaking parameters, rerunning scripts, dumping chunks to the console, and comparing outputs manually.

I built a tool to make that workflow easier.

Meet the "AabiTech RAG Chunking Simulator" (https://aabitech.com/tools/rag-chunking-simulator) — an interactive workspace for experimenting with chunking strategies before integrating them into your RAG pipeline.

What you can do

Compare strategies: Experiment with fixed-size, recursive, sentence-aware, paragraph-aware, Markdown-aware, and other splitting approaches.
Inspect boundaries: Visualize how source text is divided and examine individual chunks and overlapping regions.
Measure trade-offs: Review chunk counts, size distributions, overlap, and estimated token and embedding costs.
Explore retrieval: Test lightweight keyword retrieval, parent-child chunking, and context-window budgets.
Export your results: Download chunks in JSON, JSONL, CSV, or text formats, and generate Python splitter examples for supported frameworks.
Save experiments: Keep configuration snapshots in your browser or share settings through URL hashes.

Built with privacy in mind

The chunking engine processes your source text locally in the browser instead of sending it to a dedicated chunking API.

That makes it useful for experimenting with documentation, code snippets, and sample datasets without unnecessarily uploading them elsewhere.

What it's useful for

This isn't a replacement for evaluating retrieval quality against your real dataset. It's a way to inspect chunking behavior, understand configuration trade-offs, and narrow down the settings worth testing in your actual pipeline.

If you're building RAG systems, working with vector databases, or experimenting with document retrieval, this workspace may save you some debugging time.

🔗 Try it and bookmark it: https://aabitech.com/tools/rag-chunking-simulator

One question for fellow RAG developers: How do you choose chunk size and overlap — fixed defaults, document-specific rules, or evaluation-driven tuning?

I'd love to hear what works in your pipelines and what you'd like to see added to the tool.

Why Your Tailwind Email Breaks in Outlook (and How to Inline It Properly

Muhammad Iqbal — Mon, 12 Oct 2026 17:37:10 +0000

You build an email in Tailwind. It looks perfect in the browser, fine in Gmail, and then desktop Outlook turns it into a mess.

If you've been there, here's why it happens and a workflow that makes it less painful.

The core problem

Tailwind classes like px-6 or bg-blue-600 don't carry any styling themselves. They point at rules in a stylesheet. Email clients don't reliably load or honor that stylesheet, and each one renders HTML with its own engine:

Flexbox and grid are unreliable in key clients
Transforms, animations and advanced selectors often fail
rem units and CSS variables can behave inconsistently
Media queries work in some clients and are ignored in others

The one thing nearly everything respects is a style attribute on the element itself. That's what "inlining" gives you.

What inlining does

Illustrative example:

<!-- Before -->
<a href="#" class="bg-blue-600 text-white px-6 py-3 font-bold">Confirm email</a>

<!-- After -->
<a href="#" style="background-color:#2563eb;color:#ffffff;padding:12px 24px;font-weight:700;">Confirm email</a>

Doing this by hand across a whole template is slow, and one missed declaration can break a section in a single client without you noticing.

The tricky parts

Responsive variants. sm: and md: need media queries, and inline styles can't contain those. The workable approach is to inline the static utilities and keep responsive rules in a <style> block. Design so the email still looks fine if those rules are ignored.

Units. Convert rem to px using a known root font size.

Layout. If a utility depends on flex or grid, plan on swapping it for a table-based structure.

Email size. Inlining repeats declarations, so HTML grows. Gmail clips messages over roughly 102 KB, which can hide your footer and unsubscribe link.

A workflow that works

Write the template in Tailwind.
Convert it to inline styles.
Read the warnings and fix fragile bits.
Check the output size.
Test in real clients, especially Outlook.
Keep the Tailwind file as your source and re-convert after every change. Don't hand-edit the inlined output.

Trying it with a browser-based converter

For step 2, I built a free converter at AabiTech: the Tailwind CSS to Email-Safe Inline Style Converter. It runs entirely in the browser, so your template isn't uploaded.

What it does:

Supports Tailwind v3 and v4, with an Auto option
Offers Conservative, Balanced and Modern Email modes
Inlines static utilities and keeps responsive rules in a style block
Reports unsupported classes instead of silently guessing
Warns about fragile features like flexbox, grid, transforms and animation
Shows size change and a Gmail 102 KB check
Accepts custom theme JSON and @theme variables, plus options for root font size, !important on responsive overrides, and Outlook-safe table hints

It doesn't promise identical rendering everywhere, and neither does any converter. Treat the warnings as a to-do list, then test in the clients your audience uses.

If the output is hard to read, run it through an HTML beautifier.

Pre-send checklist

[ ] No flex or grid in the layout
[ ] Warnings reviewed
[ ] Size comfortably under Gmail's clip limit
[ ] Responsive rules are enhancements, not requirements
[ ] Tested in Gmail, Outlook, Apple Mail and mobile
[ ] Dark mode checked

Over to you

What's the worst email client bug you've fought? Do you inline at build time, or use something like MJML or a framework instead? I'd like to hear what's working for your team.