DEV Community: Yasser Elgammal

Green Framework: From a Small Experiment to a PHP Framework

Yasser Elgammal — Sat, 12 Sep 2026 00:21:27 +0000

Green started as a small experiment. 🌱

I didn't have a big roadmap.

I just wanted to build a PHP framework myself and understand more of what happens underneath the frameworks I use every day.

The first version was simple. I wasn't trying to build something that could compete with existing frameworks. I was mainly interested in the process of building one.

Some parts were there from the beginning. Others came later. But almost everything has evolved and improved along the way.

From the Basics

Routing and database access were part of Green from the early versions.

Then the framework started growing around them.

Middleware
Authentication
APIs
Sessions
Caching
Testing
Localization
Validation
Service Providers
Exception Handling
Relations & Pagination
Admin Features

And many other smaller pieces.

But adding features wasn't the only part of the journey.

A big part of it was going back to things I had already built and asking:

Can this be simpler?
Does this belong here?
Is this really the responsibility of this class?

Refactoring Became Part of the Process

One example is the router.

At some point, the router was doing too much.

Instead of continuing to add more code to it, I split its responsibilities into smaller components such as:

RouteRegistrar
RouteRegistry
RouteMatcher
MatchedRouteDispatcher
RouteInvoker

FastRoute is still used underneath, but the routing API belongs to Green.

That kind of refactoring happened in other parts of the framework too.

The goal wasn't to make Green bigger.

It was to make it easier to understand and maintain.

From v1 to v2

The early versions were mostly about getting the foundation working.

As Green moved toward v2, more attention went into the architecture and developer experience.

Some of the things that evolved along the way:

Service Providers became a native part of the framework
Database and relation handling evolved
Exception handling became more consistent
Routing became more structured
Testing increased
Session handling became safer
Session IDs are regenerated after login
Sessions can be invalidated where needed

They came from actually working on the framework and finding things that needed to change.

22 Releases Later

Today, Green has 22 releases since April 2026.

That's roughly one release every week.

The number itself isn't the most important thing for me.

What I like about looking back at the releases is seeing how much changed between the first version and the current one.

A small experiment turned into a framework with its own structure, conventions, and ideas.

Getting Started

Starting a new Green project is straightforward.

composer create-project yasser-elgammal/green my-app

You can also check the source code and documentation on GitHub:
Green Framework on GitHub

Using Green in a Real Environment

One of the best parts of this journey was getting the chance to use Green in a real production environment.

Using Green in a real application gave me a different perspective.

Some things that looked good while building them needed to be simplified.

Some assumptions had to be reconsidered.

And some parts became much more valuable when they were actually used.

That's probably one of the biggest differences between building something as an experiment and building something that has to work for a real application.

Still Building

Green is far from finished.

There are still things I want to improve, features I want to build, and architectural decisions I want to revisit.

But looking back from v1 to the current release, I'm happy with how far the project has come.

It started as a small experiment.

Now it's a framework I'm continuing to build, use, and learn from.

Still building. 🌱

What Is an AI Harness? A Practical Guide with a Laravel CMS Example

Yasser Elgammal — Thu, 03 Sep 2026 22:03:42 +0000

An AI harness is a structured set of files, rules, skills, workflows, and project context that surrounds an AI coding agent.

Instead of repeating the same instructions in every prompt, the harness gives the agent a consistent way of working across tasks and sessions.

And that's the key idea:

Prompting tells the agent what to do. A harness tells it how to work.

The Problem

If you've spent any time pairing with an AI coding agent, you've probably seen the same problems:

It forgets your project conventions.
It touches files it shouldn't.
It skips important validation.
It considers a task "done" too early.
You have to explain the same architecture repeatedly.
Every new session feels like starting from zero.

So you keep writing prompts like:

"Remember to use Policies for authorization."

"Run the tests before you're done."

"Don't modify unrelated files."

"Follow our existing service architecture."

These instructions are valuable.

But they shouldn't have to live in your prompt every time.

They should live in the environment around the agent.

That's where an AI harness comes in.

What Is an AI Harness?

An AI harness is the structured layer around an AI coding agent that defines:

Rules — what must always be true.
Skills — how specific engineering tasks should be handled.
Workflows — the order in which work should happen.
Context — facts about the current project.
Agents — roles and authority, when multiple specialized roles are useful.
Adapters — how different coding tools connect to the same harness.

The model provides the reasoning.

The harness provides the discipline.

Think about a simple task:

"Add an endpoint for publishing posts."

Without a harness, the process might look like:

Understand request
↓
Explore project
↓
Guess conventions
↓
Implement
↓
Run some tests
↓
"Done"

With a harness:

Identify task
↓
Load relevant rules
↓
Load project context
↓
Select required skills
↓
Follow workflow
↓
Implement smallest change
↓
Validate
↓
Test
↓
Review
↓
Verify requirement
↓
Done

The difference isn't necessarily a smarter model.

It's a more reliable operating environment.

Prompt vs. Harness

A prompt is ideal for task-specific intent.

A harness is ideal for persistent engineering knowledge.

Plain Prompt	AI Harness
Instructions rewritten when needed	Instructions persist in the project
Consistency depends on the prompt	Same rules across sessions
Project knowledge gets repeated	Project knowledge is stored
Rules and context are often mixed	Responsibilities are separated
Human decides when it's "done"	Definition of Done can be explicit
Safety depends heavily on instructions	Approval gates can be defined
Harder to reuse	Structure can be reused across projects

For example, instead of writing this every time:

"Use Form Requests for validation, Policies for authorization, feature tests for endpoints, don't touch unrelated files, and run php artisan test."

You can store those decisions once.

Then your actual prompt can remain simple:

"Add an instant-publish button to the post editor."

The harness supplies the engineering context.

The Architecture of an AI Harness

A practical harness can look like this:

ai-harness/
├── AGENTS.md        # Entry point / index
├── agents/          # WHO acts
├── skills/          # HOW to handle a concern
├── rules/           # WHAT must always be true
├── workflows/       # IN WHAT ORDER to work
├── context/         # WHAT is true about this project
└── adapters/        # Tool-specific integration

These components have different responsibilities.

Agents — WHO

Defines roles and authority.

agents/
├── developer.md
├── reviewer.md
└── debugger.md

For example, a Developer may implement changes while a Reviewer focuses on inspecting them.

Not every project needs multiple agents. Start with one if that's enough.

Skills — HOW

Reusable engineering knowledge.

skills/
├── testing-strategy.md
├── api-design.md
├── database-design.md
└── code-review.md

A testing skill can explain how the project approaches tests, factories, edge cases, and assertions.

Rules — WHAT MUST ALWAYS BE TRUE

Rules are constraints.

rules/
├── core-rules.md
├── approval-gates.md
└── definition-of-done.md

Examples:

Do not modify unrelated files.

Do not bypass authorization.

Do not introduce unnecessary dependencies.

Do not declare a task complete without validation.

Destructive operations require human approval.

Workflows — IN WHAT ORDER

A workflow defines the sequence for a type of task.

For example:

workflows/
├── feature-development.md
├── bug-fix.md
└── release.md

A feature workflow could be:

Understand
↓
Inspect
↓
Plan
↓
Implement
↓
Test
↓
Review
↓
Verify

Context — WHAT IS TRUE ABOUT THIS PROJECT

Context contains project-specific facts.

context/
├── project.md
├── architecture.md
├── domain.md
└── conventions.md

For example:

project.md
→ Laravel 11
→ PHP 8.3
→ MySQL
→ Redis

architecture.md
→ Form Requests
→ Policies
→ Services
→ Feature Tests

This is the part that changes most from project to project.

Rule vs. Skill vs. Workflow vs. Context

One instruction can actually contain four different concepts.

Take:

"Always run tests before finishing."

It can become:

Rule: A change must be validated before completion.
Skill: How to write and run appropriate tests.
Workflow: Validation happens before the task is considered complete.
Context: The project's actual test command is php artisan test.

This separation is important.

It prevents one giant instruction file from becoming the place where everything lives.

A Laravel CMS Example

Imagine a Laravel CMS with:

Posts
Categories
Users
Roles
Publishing workflows

The repository could look like:

laravel-cms/
├── AGENTS.md
├── ai-harness/
│   ├── AGENTS.md
│   ├── agents/
│   ├── skills/
│   ├── rules/
│   │   ├── core-rules.md
│   │   ├── approval-gates.md
│   │   └── definition-of-done.md
│   ├── workflows/
│   ├── context/
│   │   ├── project.md
│   │   ├── architecture.md
│   │   ├── domain.md
│   │   └── conventions.md
│   └── adapters/
├── app/
├── database/
├── tests/
└── ...

Now imagine the task is:

"Add an instant-publish button for a post from the admin panel."

The harness can guide the agent through:

Task arrives
↓
Identify task type
↓
Feature Development workflow
↓
Load core Rules
↓
Load relevant Context
↓
Select required Skills
↓
Check Approval Gates
↓
Implement smallest possible change
↓
Run validation
↓
Run tests
↓
Review changes
↓
Verify original requirement
↓
Done

Notice that the agent doesn't necessarily need every project document.

A good harness can instruct it to load only the context relevant to the task.

For this feature, that might mean:

project.md       ✓
architecture.md  ✓
domain.md        ✓
conventions.md   ✓
payments.md      ✗

The exact loading behavior depends on the coding tool, but the harness should make the intended boundaries explicit.

"Done" Must Be Checkable

One of the biggest benefits of a harness is defining what "done" actually means.

Creating the button isn't enough.

The agent should verify:

✓ Button exists
✓ Correct users can access it
✓ Authorization is enforced
✓ Post becomes published
✓ Invalid states are handled
✓ Relevant tests pass
✓ No unrelated files were changed
✓ Original requirement is satisfied

That's what a:

rules/definition-of-done.md

can establish.

The goal is simple:

"Code exists" ≠ "Task is complete."

Approval Gates

Some operations are routine.

Others are risky.

Imagine the agent receives:

"Delete this category and all its posts."

That's potentially destructive.

The harness can define an approval gate:

Potentially destructive operation
↓
Explain impact
↓
Stop
↓
Request human approval
↓
Continue only after approval

This is an important distinction:

A good agent shouldn't only know how to continue. It should also know when to stop.

Whether a particular tool can technically enforce every gate depends on the tool, but the policy itself belongs in the harness.

Codex and Cursor

The harness should remain tool-agnostic.

Your engineering rules shouldn't need to change because you switched from Codex to Cursor.

Only the entry point changes.

Conceptually:

                 Shared AI Harness
                        │
             ┌──────────┴──────────┐
             │                     │
           Codex                 Cursor
             │                     │
        AGENTS.md            .cursor/rules/

For Codex, keep the repository-level AGENTS.md thin:

## Laravel CMS — Agent Entry Point

Before performing engineering work in this repository,
read and follow `ai-harness/AGENTS.md`.

The harness defines the project's:
- Agents
- Skills
- Rules
- Workflows
- Context

Do not duplicate the harness content here.

For Cursor, use its project rules under:

.cursor/
└── rules/
    └── harness.mdc

That rule can simply point the agent toward the shared harness.

The principle is:

One source of truth. Thin tool adapters.

Don't copy your entire engineering system into both AGENTS.md and Cursor rules.

Where Should Each Thing Go?

When you're unsure where an instruction belongs, ask:

Question	Put it in
"This must always be true."	`rules/`
"This is how we do this."	`skills/`
"These steps must happen in this order."	`workflows/`
"This is true about this project."	`context/`
"This role has specific authority."	`agents/`
"This is how Cursor/Codex connects."	`adapters/` / entry point

This simple distinction prevents the harness from becoming another giant instruction dump.

Start Small

You don't need a huge framework on day one.

A useful starting point could be:

ai-harness/
├── AGENTS.md
├── rules/
│   ├── core-rules.md
│   └── definition-of-done.md
├── workflows/
│   ├── feature-development.md
│   └── bug-fix.md
├── skills/
│   └── testing-strategy.md
└── context/
    ├── project.md
    └── architecture.md

Then grow it when you notice repetition.

If you keep explaining the same thing to the agent, that's a signal that the knowledge probably belongs in the harness.

Final Takeaways

An AI harness isn't just a bigger prompt.

It's a structured engineering environment that gives an AI coding agent:

Consistency
Project knowledge
Reusable engineering practices
Repeatable workflows
Clear completion criteria
Safety boundaries

The goal isn't to make the model smarter.

It's to make the model more predictable and reliable inside your project.

The strongest principle is:

Don't put more instructions in the prompt. Put persistent engineering knowledge in the environment around the agent.

Prompting tells the agent what you want.

Harness engineering tells it how to work.

And that's the real shift:

From prompting an AI to engineering the environment in which the AI works.

Green Framework v2: Modern PHP Framework for Web Development

Yasser Elgammal — Thu, 30 Jul 2026 10:57:03 +0000

Green Framework is a modern and lightweight PHP framework designed to make building web applications and APIs simpler, faster, and more predictable.

Green focuses on clean architecture, explicit code, and modern PHP features without adding unnecessary complexity.

Instead of hiding what happens behind the scenes, Green aims to give developers a clear understanding of how their application works.

🚀 Why Green?

Green provides the essential tools you need to build modern PHP applications while keeping the framework lightweight and easy to understand.

✨ Modern PHP

Green takes advantage of modern PHP features such as Attributes, Reflection, Type Declarations, and modern object-oriented architecture.

For example, routes can be defined directly inside controllers:

#[Route('GET', '/users/{id}', name: 'users.show')]
public function show(int $id): array
{
    return [
        'id' => $id,
    ];
}

No separate route file is required for simple controller-based routing.

🛣️ Powerful Routing

Green provides an attribute-based routing system powered by FastRoute.

You can define:

HTTP methods
Route parameters
Named routes
Route middleware
Authorization policies

Named routes can also be used to generate URLs:

route('users.show', ['id' => 5]);

This keeps your application routing organized and avoids hardcoding URLs throughout your application.

🧩 Lightweight Service Container

Green includes a lightweight Service Container with:

Dependency injection
Auto-wiring
Bindings
Singletons
Explicit instances
Circular dependency detection

For example:

class UserService
{
    public function __construct(
        private UserTable $users
    ) {}
}

Dependencies can be resolved automatically through PHP Reflection while still keeping the container simple and predictable.

⚙️ Centralized Configuration

Green includes a centralized configuration system designed to provide a single, immutable configuration snapshot for the application.

Configuration can come from:

Framework defaults
Environment variables
config/*.php
Application overrides
Cached configuration

For production environments, configuration can also be cached:

green config:cache

Green also provides:

green config:show
green config:clear

Sensitive values such as passwords, tokens, and API keys are automatically redacted when configuration is displayed.

🗄️ Database & ORM

One of Green's main architectural decisions is its database layer.

Instead of putting database logic directly inside models, Green separates data from persistence.

Table Gateway & Data Mapper

The Model represents your data, while the Table handles database operations.

Model
  ↓
Data

Table
  ↓
Database Operations

This approach is based on the Table Gateway and Data Mapper patterns and keeps models free from database logic.

🔎 Fluent Query Builder

Green provides a simple fluent query layer through GreenQuery.

$users = $userTable->query()
    ->where('status', 'active')
    ->whereGroup(fn ($query) => $query
        ->where('role', 'admin')
        ->orWhere('score', '>=', 90)
    )
    ->latest()
    ->fetch();

It supports:

where
orWhere
Grouped conditions
Ordering
Pagination
Aggregates
exists
first
Limits and offsets

The query layer is built on top of Doctrine DBAL while keeping Green's API simple.

🔗 Relations & Eager Loading

Green includes a relation engine supporting:

hasOne
hasMany
belongsTo
manyToMany

Relations can be loaded using:

$userTable->include('posts');

Nested relations are supported as well:

$userTable->include('posts.comments');

Green's eager-loading system is designed to avoid the N+1 query problem by loading related records using optimized WHERE IN (...) queries and stitching the results together in memory.

🧠 Include Query Language — IQL

For APIs that need dynamic eager loading, Green introduces IQL — Include Query Language.

For example:

comments(limit:5,order:desc).author(select:id|name)

This allows API consumers to describe which relations they want and how those relations should be loaded.

Green parses, validates, and resolves the query before applying it to the underlying database query.

✅ Validation

Green provides a Payload system for handling validated request data.

A Payload can handle:

Data preparation
Authorization
Validation
Structured validation errors

For example:

class CreateUserPayload extends Payload
{
    public function rules(): array
    {
        return [
            'email' => v::email(),
            'name' => v::stringType()->notEmpty(),
        ];
    }
}

Validation errors are automatically converted into appropriate HTTP responses.

🛡️ Authorization

Green provides an explicit authorization system based on Policies and an Authorizer.

You can protect controller actions using Attributes:

#[PolicyAttribute('update', 'post')]
public function edit(int $id)
{
    //
}

This keeps authorization rules separate from business logic and makes permissions easier to understand.

🔐 Built-in CSRF Protection

Green includes CSRF protection for state-changing HTTP requests.

It provides:

Cryptographically secure tokens
Timing-safe validation
Single-use tokens
Token expiration
Configurable token limits
Configurable exception paths

Tokens can be generated for forms and validated automatically through middleware.

🚨 Error & Exception Handling

Green includes a centralized error-handling system capable of handling:

Exceptions
PHP errors
Fatal errors
Structured error records
Logging
Error deduplication
Rate limiting

Errors can be returned as either JSON or HTML, depending on the request.

Stack traces are only exposed when debug mode is enabled.

This helps keep production applications safer while still providing useful debugging information during development.

🌍 Localization

Green includes a localization engine with support for:

JSON translation files
Database translations
Locale fallback
Variable interpolation
Pluralization
Arabic plural rules

For example:

t('messages.welcome');

The translation system supports locale fallback such as:

ar_EG
  ↓
ar
  ↓
fallback locale
  ↓
default locale

Green also provides first-class support for Arabic localization.

📁 Drive Storage

Green provides a filesystem abstraction called Drive.

It supports operations such as:

drive()->put(...)
drive()->get(...)
drive()->delete(...)
drive()->exists(...)

The storage system supports multiple drivers and can be extended with custom drivers.

It also includes security protections against:

Directory traversal
Null-byte injection
Invalid control characters
Root escape through symlinks

Testing storage operations is also possible through an in-memory fake driver.

⚡ Cache

Green provides a cache abstraction supporting multiple drivers, including:

File
Array
Database
Redis

You can use the remember() pattern to retrieve or calculate cached values:

cache()->remember('users', 3600, function () {
    return getUsers();
});

This keeps caching logic independent from the underlying storage implementation.

📡 Signals — Event System

Green includes a lightweight event system called Signals.

Listeners can subscribe using Attributes:

#[Signal('user.registered')]
public function handle(UserRegistered $event)
{
    //
}

Events can be dispatched simply:

dispatch('user.registered', $user);

This provides a clean way to decouple application components and react to domain events.

🌐 External API Integrations

Green includes the Connect subsystem for consuming external HTTP APIs.

It is built on top of Guzzle and encourages keeping API communication inside dedicated service objects.

This helps keep external API logic isolated from controllers and business logic.

🧱 Middleware Pipeline

Green uses an Onion-style middleware pipeline.

A request moves through middleware before reaching the controller and then travels back through the same pipeline when a response is returned.

Request
   ↓
Middleware
   ↓
Middleware
   ↓
Controller
   ↓
Response
   ↓
Middleware
   ↓
Middleware

This makes authentication, authorization, logging, CORS, CSRF, and other request-level concerns easier to organize.

🎯 Explicit by Design

Green follows a few simple principles:

Explicit over Magic
Minimal Core
Predictable Runtime Behavior
Clean Separation of Responsibilities
Extensible Architecture
Modern PHP
Low Unnecessary Complexity

The goal is not to replace every tool in the PHP ecosystem.

The goal is to provide a clean foundation that gives developers the tools they need without forcing them into unnecessary abstractions.

⚡ Installation

You can create a new Green Framework project using Composer:

composer create-project yasser-elgammal/green app-name

Then start building your application using modern PHP and Green's lightweight architecture.

📚 Documentation & Source Code

The Green Framework documentation and source code are available on GitHub.

You can explore the architecture, read the documentation, open issues, suggest improvements, or contribute to the project.

💚 Conclusion

Green Framework v2 has grown from a simple PHP framework into a modern foundation for building web applications and APIs.

It combines:

Modern PHP
Attribute-based routing
Dependency injection
Centralized configuration
Validation
Authorization
CSRF protection
Localization
Storage
Caching
Events
API integrations
Table Gateway ORM
Fluent queries
Relations and eager loading
Advanced Include Queries
Centralized error handling

while keeping its original philosophy:

Build with less magic. Understand more.

Green is for developers who want a framework that helps them move fast without making the code harder to understand.

Google Gemini Integration for Laravel: Simple, Clean, and Lightweight

Yasser Elgammal — Wed, 17 Jun 2026 20:53:50 +0000

Simplifying Google Gemini Integration in Laravel

AI is becoming a core part of modern applications, from content generation and chat experiences to intelligent assistants and automation.

For Laravel applications that only need Google Gemini, a lightweight and dedicated integration can provide a simpler developer experience.

"laravel-gemini" is a Laravel package that provides a clean way to interact with the Google Gemini API.

Features

Simple text generation
Chat-style conversations
Raw Gemini API access
Normalized responses
Facade and Dependency Injection support
Laravel configuration and ".env" support
Custom generation options per request
Exception handling

Installation

composer require yasser-elgammal/laravel-gemini

Basic Usage

use YasserElgammal\LaravelGemini\Facades\Gemini;

$response = Gemini::generate('Explain Laravel service providers');

Chat Example

$response = Gemini::chat([
    [
        'role' => 'user',
        'content' => 'Hello Gemini',
    ],
]);

Visit the Package on GitHub

Check out the source code, documentation, and contribute to the project:

GitHub Repository

Laravel Compatibility

The package supports:

Laravel 10
Laravel 11
Laravel 12
Laravel 13

with PHP 8.1+.

Documentation

Currently, the documentation is available through the README, covering the core usage and examples. More production-level examples and best practices will be added in future updates.

Feedback & Contributions

Feedback, issues, and contributions are always welcome. The goal is to make integrating Google Gemini into Laravel applications as simple and enjoyable as possible.

Green Framework: Simple & Modern PHP Framework for Fast Development

Yasser Elgammal — Tue, 07 Apr 2026 00:25:58 +0000

Green Framework is a simple and modern PHP framework built to make development faster and easier.

It focuses on clean code and uses modern PHP features like Attributes, so you can define things like routes directly inside your controllers without extra files.

🚀 Why use Green?

Simple and lightweight
Clean and readable code
Fast to build with
Great for small to medium projects

⚡ Installation

You can install Green Framework using Composer:

composer create-project yasser-elgammal/green

📚 Documentation

You can view the full documentation and explore the project on GitHub:

👉 Project link on GitHub

Feel free to explore the code, open issues, or contribute to the project 🚀

💡 Conclusion

Green Framework is a good choice if you want a clean and simple way to build modern PHP applications without unnecessary complexity.

Introducing a Rate Limiter Library for Go

Yasser Elgammal — Sun, 18 Jan 2026 22:41:52 +0000

In modern backend systems, rate limiting is essential.

Without it, APIs are exposed to abuse, resource exhaustion, and unfair usage.

That’s why I built a production-ready, thread-safe rate limiter library in Go, based on the Token Bucket algorithm.

Why Token Bucket?

I chose the Token Bucket algorithm because it:

Allows controlled bursts of traffic
Provides smooth request flow
Is widely used in production systems
Is simple to understand and reason about

Each client gets a bucket of tokens that refills over time.

Requests consume tokens — once the bucket is empty, requests are rejected.

Library Highlights

This library focuses on correctness and simplicity:

Production-ready & thread-safe
Token Bucket algorithm with burst support
Fast in-memory storage
Detailed rate limit results (remaining, retry-after, reset time)
Extensive unit tests and race-condition testing
Optional cleanup for stale entries

Quick Example

config := limiter.Config{
    Rate:     10,
    Duration: time.Second,
    Burst:    20,
}

store := store.NewMemoryStore(5 * time.Minute)
rateLimiter, _ := limiter.NewTokenBucket(config, store)

if rateLimiter.Allow("user123") {
    fmt.Println("Request allowed")
}

With just a few lines, you get a reliable rate limiter ready for production.

Perfect For

REST APIs
Go microservices
Public-facing services
Internal tools

Anything that needs fair and controlled request handling.

Open Source

The project is open source under the MIT license and open for contributions.

GitHub:

https://github.com/yasserelgammal/rate-limiter

If you find it useful, feel free to leave a ⭐️

It really helps support open-source work.

Understanding Technical Debt in Modern Software Development

Yasser Elgammal — Thu, 15 Jan 2026 19:15:10 +0000

Technical Debt is one of the most important concepts in software engineering and product development. It refers to the future cost created when development teams choose quick, temporary, or sub-optimal solutions instead of implementing the best long-term approach.

This article explains the meaning of technical debt, why it happens, its risks, and best practices to manage it effectively.

What Is Technical Debt? — Definition

Technical Debt is the “extra work” a team will have to do later because they took shortcuts during development.

Just like financial debt:

You borrow time now (by coding quickly)
You pay back more time later (due to fixes, refactoring, bugs)

Why Does Technical Debt Happen?

Technical debt is not always caused by mistakes—it often results from business needs. Common causes include:

1. Tight deadlines

Teams prioritize delivery speed over clean architecture.

2. Changing requirements

Unclear or shifting requirements lead to temporary solutions.

3. Legacy systems

Old technologies and outdated code create unavoidable debt.

4. Lack of testing

Skipping automated tests increases future risks.

5. Quick fixes

Temporary patches remain longer than expected.

Examples of Technical Debt

Hard-to-read or unmaintainable code
Missing documentation
Poor architecture or structure
Using deprecated libraries
Duplicated logic
Large modules without clear separation
No automated testing

These issues may not break the system today, but they slow development dramatically over time.

Why Technical Debt Matters (Business Impact)

Technical debt has a direct impact on product quality and delivery speed:

1. Slower development

New features take longer because the codebase becomes harder to modify.

2. More bugs

Quick solutions often introduce hidden issues.

3. Higher maintenance cost

Developers spend more time fixing issues than building features.

4. Reduced system stability

Legacy components become fragile.

5. Lower team morale

Developers become frustrated when working with messy or outdated code.

Is Technical Debt Always Bad?

No, sometimes it’s strategic.

Teams may intentionally take technical debt to:

Release an MVP quickly
Validate an idea
Meet urgent business requirements
Beat a competitor to market

But like real debt, it must be tracked and repaid.

How to Manage and Reduce Technical Debt

1. Plan regular refactoring

Allocate time each sprint for code improvements.

2. Enforce clean code standards

Use style guides, naming conventions, and architecture rules.

3. Write automated tests

Unit tests, integration tests, and CI pipelines reduce long-term risk.

4. Track technical debt

Use backlog items, documentation, or dashboards.

5. Educate stakeholders

Explain the business impact of unmanaged technical debt.

6. Avoid “quick fixes” mentality

Make temporary solutions clearly documented and time-boxed.

Conclusion

Technical Debt is a natural part of any software project. It becomes dangerous only when ignored.

By understanding its causes and actively managing it through refactoring, testing, and good engineering practices, teams can build scalable, stable, and future-proof systems.

Boost Your Laravel Productivity with “Laravel Debug Remover” VSCode Extension

Yasser Elgammal — Tue, 18 Nov 2025 23:07:59 +0000

Debugging with dd() is part of every Laravel developer’s workflow.
But forgetting a debug statement inside a controller or Blade file can break production or interrupt API responses.

Laravel Debug Remover automatically scans and removes all dd() debug statements from your PHP and Blade files.

Key Features

Two Modes

Current File – Cleans debug statements only in the file you're working on
Entire Workspace – Scans and cleans your whole project

Smart Exclusions

Automatically skips:

vendor
node_modules
storage
bootstrap/cache

You can customize the ignored folders from the extension settings.

Fully Configurable

Add your own directory exclusions via settings.json.
Perfect for large Laravel or monolithic codebases.

High Performance

Fast and optimized scanning — ideal for projects with hundreds of files.

Usage

Press CTRL + P and choose:

Remove all debug statements (Current File)
Remove all debug statements (Entire Workspace)

Supports Both PHP & Blade

Blade templates are parsed safely without breaking UI or logic.
The extension intelligently handles both PHP and Blade syntaxes.

Download

📥 VSCode Marketplace:
Download from VSCode Marketplace

Final Thoughts

This extension solves a common and painful issue every Laravel developer faces.
If it prevents a production mistake or speeds up your workflow, then it has achieved its goal.

Introducing Lara SMS – A Flexible Laravel SMS Gateway Package

Yasser Elgammal — Fri, 24 Oct 2025 16:44:11 +0000

I’m excited to introduce my new Laravel package, Lara SMS, designed to make SMS integration in Laravel projects easier, cleaner, and more flexible.

💡 Why Lara SMS?

Integrating SMS gateways can often be repetitive and inconsistent across projects.
Lara SMS provides a unified and expressive API that allows you to send messages through multiple gateways, all while keeping your codebase elegant and maintainable.

⚙️ Key Features

✅ Multi-provider support
Built using the Strategy Pattern, allowing seamless integration with multiple SMS gateways.

✅ Fluent Builder
Provides a clean and expressive syntax for message construction using a chainable, fluent interface.

✅ Fallback Strategies
Choose between “Try All” or “Fail Fast” approaches when handling failed gateway attempts.

✅ Automatic Retries
Automatically retries sending messages on temporary failures to ensure reliability.

✅ Comprehensive Logging
Tracks and logs all SMS operations for better monitoring and debugging.

🧩 Installation

Install the package via Composer:

composer require yasser-elgammal/lara-sms

🧠 Behind the Scenes

This project taught me a lot about designing scalable and extendable Laravel packages, particularly around architectural design patterns like Strategy and Builder.

My goal was to create something that’s both powerful and developer-friendly, making SMS workflows in Laravel projects smoother than ever.

🔗 GitHub:
https://github.com/yasserelgammal/lara-sms

💬 Feedback Welcome

I’m always open to feedback, ideas, and contributions.
If Lara SMS helps simplify your workflow or if you have suggestions for improvement, I’d love to hear from you!

How to Monitor and Save Server Disk Space in Laravel

Yasser Elgammal — Wed, 10 Sep 2025 16:59:07 +0000

When working on Laravel projects, it’s important to keep an eye on your server’s storage usage. Large folders can easily go unnoticed until your server starts running out of space.

Here’s a small Laravel helper that:

Calculates the size of each folder inside storage/.
Displays both raw size (bytes) and a human-readable format (KB / MB / GB).
Allows sorting results ascending or descending.

This helps a lot when monitoring a live server, so you can quickly find which folders are consuming the most space.

Full code: 👇
👉 View the code on Gist

⚡ This is a lightweight utility, but it can save you time and help keep your servers clean.

Note:

The code works starting from Laravel 10+.
This is just a small idea, and of course, it’s open for customization or further development.

🙏 If you found this useful, share it with your network it might save someone else hours of debugging or running out of server space.

Why Should You Use Traits in PHP? - 5 Reasons

Yasser Elgammal — Wed, 13 Aug 2025 11:23:47 +0000

Introduction:

In PHP, traits are a powerful tool for reusing code across different classes. They help you keep your codebase clean, flexible, and easy to maintain, Here are five key reasons to use them:

1. Reuse code in multiple classes without copying it

Traits let you write a method once and use it in many classes, so you don’t have to duplicate the same logic everywhere.

2. Avoid single inheritance limit

Since PHP only allows one parent class, traits give you a way to add functionality from multiple sources at the same time.

3. Keep code DRY (Don’t Repeat Yourself)

Putting shared methods in a trait ensures you write them once and reuse them, reducing the chance of mistakes or inconsistencies.

4. Mix behaviors into unrelated classes

Traits allow you to add the same features to classes that are not related in the inheritance hierarchy.

5. Easy to maintain

If you need to update a shared method, you just change it in the trait, and all classes using it automatically get the update.

Summary

PHP traits let you share and reuse methods across multiple unrelated classes, bypassing the single inheritance limit. They help keep code DRY by centralizing common logic, making it easier to maintain—any change in the trait applies to all classes using it.

How to Structure Your Tests Using AAA (Arrange / Act / Assert)

Yasser Elgammal — Sat, 02 Aug 2025 06:27:45 +0000

When writing Unit or Feature tests in Laravel, one of the most effective ways to keep your tests clean and easy to follow is by using the AAA pattern.

What is AAA?

AAA stands for:

Arrange : Set up your data and dependencies
Act : Execute the behavior or function you want to test
Assert : Verify that the result matches your expectations

This structure makes your tests:

Easier to read
Easier to maintain
Easier to debug

Why Use AAA?

It helps you avoid writing "messy" tests where setup, execution, and assertions are all mixed together.

By clearly separating the 3 phases of testing, you're more likely to catch bugs early, understand what each test is doing at a glance, and maintain consistency across your codebase.

Laravel Example

Here’s a simple Feature Test example following the AAA pattern:

public function test_run_todo_show(): void
{
    // Arrange
    $todo = Todo::factory()->create();

    // Act
    $response = $this->get("/todos/{$todo->id}");

    // Assert
    $response->assertStatus(200);
    $response->assertViewIs('todos.show');
    $response->assertSee($todo->title);
}

Summary

The AAA pattern stands for Arrange, Act, Assert.
It separates test setup, execution, and verification for clarity and maintainability.
This structure improves readability, consistency, and debugging.