Now things get interesting. Let's talk about how Git actually tracks history, and why branches are one of the biggest lies in software development. Not lies in a bad way. They are just far simpler than most people think.

What a Commit Really Is

We touched on this briefly in Part 1, but now we are going to go deeper. A commit object is deceptively simple. It contains exactly three things:

1. A pointer to a tree object (the snapshot of your project at that moment)

2. A pointer to the parent commit (or two parents if it is a merge commit)

3. Metadata: author, committer, timestamp, and the commit message

That is it. There is no diff stored in a commit. No line-by-line change tracking. Just a full snapshot of your project tree, plus a link back to where you came from.

So your project history is not a sequence of diffs. It is a linked list of snapshots.

Commit C  -->  Commit B  -->  Commit A  -->  (root, no parent)
   |               |               |
  tree C          tree B          tree A

Every commit knows its parent. Commit A is the first commit (no parent). Commit B points back to A. Commit C points back to B. That chain is your entire Git history.

When you run git log, Git starts at the latest commit and follows those parent pointers backwards. That is literally all it is doing.

The beautiful thing here is that two commits can share parts of the same tree. If you only changed one file, the new commit's tree reuses all the unchanged blob objects from the previous tree. Git is efficient like that.

Branches Are Just Text Files

This is the one that genuinely surprises people. Run this in any Git repo:

cat .git/refs/heads/main

You will see something like:

a3f8b1c2d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9

That is it. A branch is a file with a 40-character commit hash inside it. Nothing more.

Creating a new branch? Git writes a new file in .git/refs/heads/ with the current commit hash.

Deleting a branch? Git deletes that file.

Switching branches? Git updates .git/HEAD to point to a different file.

So when your teammate says "I just created a feature branch," all they did was write a 40-character string into a new file. The code did not move anywhere. No files were copied. Nothing was duplicated.

Think of it like a sticky note. Your codebase is a city. A branch is just a sticky note on your desk that says "I am currently looking at intersection A3F8B1C2." When you create a new branch, you grab a second sticky note and write the same address on it. Two notes, same location, zero duplication.

This also explains why branches in Git are so cheap to create and delete, unlike older version control systems that actually copied entire directory trees when you branched.

HEAD: The Pointer to the Pointer

Every Git repo has a special file at .git/HEAD. Take a look:

cat .git/HEAD

On a normal working branch, you will see:

ref: refs/heads/main

HEAD is not pointing at a commit directly. It is pointing at a branch name. HEAD says: "I am on the main branch. Whatever commit main points to, that is where I am."

This is called a symbolic ref. HEAD knows the branch, and the branch knows the commit.

Now, here is where people get confused. Run git checkout on a specific commit hash instead of a branch name:

git checkout a3f8b1c2

Now look at .git/HEAD:

a3f8b1c2d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9

HEAD now points directly to a commit hash, not to a branch. This is called detached HEAD state. Git even warns you about it with that slightly alarming message: "You are in 'detached HEAD' state."

Do not panic. All it means is: you are looking at a commit that is not the tip of any branch. If you make new commits from here, those commits will not be attached to any branch. They will just be floating in history with no branch pointing to them.

This is why Git warns you. If you switch away without creating a branch first, those commits become unreachable. Well, mostly unreachable. We will cover how to recover them in the reflog section.

Detached HEAD typically happens when you:

• Check out a specific commit hash directly

• Check out a tag

• Land in the middle of an interactive rebase

To get back to safety, just run git checkout main (or whatever your branch is called) and HEAD becomes a symbolic ref again.

What Actually Happens When You git commit

This is the full picture. Let's walk through every step that fires when you run git commit -m "Add payment processing".

Step 1: Build blob objects from the index. The index (.git/index) holds the staged files. Git takes each file and writes a blob object for it into .git/objects/. Files that have not changed reuse their existing blob objects.

Step 2: Build tree objects. Git assembles a tree object that represents your project's directory structure, pointing to all the blob objects for your files.

Step 3: Create the commit object. Git creates a new commit object that contains: the SHA of the new tree, the SHA of the current HEAD commit as the parent, and your metadata (author, message, timestamp).

Step 4: Update the branch ref. The current branch file in .git/refs/heads/ gets updated. It now contains the hash of the new commit.

Step 5: HEAD stays the same. HEAD still says ref: refs/heads/main. But now main points to your new commit instead of the previous one.

Visually:

BEFORE commit:
HEAD --> main --> [commit B]

AFTER commit:
HEAD --> main --> [commit C] --> [commit B]

HEAD did not move. The branch moved. HEAD follows because it points to the branch.

This is a really satisfying thing to understand. When you commit, you are not "saving to HEAD." You are extending the branch one commit forward, and HEAD trails along automatically.

Merging Under the Hood

Merges are actually two very different operations depending on the situation. Git decides which to use based on the history.

Fast-Forward Merge

Say you are on main and you want to merge in feature/payment. But here is the thing: since you created feature/payment, nobody has committed anything new to main. Your branch history looks like this:

main:           A --> B
feature/payment:      B --> C --> D

main is directly behind feature/payment. There is a straight path from B to D with no diverging. Git does not need to create a merge commit here. It just moves the main pointer forward to D.

AFTER fast-forward:
main:           A --> B --> C --> D

That is a fast-forward merge. The branch pointer just slides forward. No new commit is created. Clean, linear history.

Three-Way Merge

Now say main has had new commits while you were working on your feature:

main:           A --> B --> E --> F
feature/payment: A --> B --> C --> D

Now there are two diverging lines of development. Git cannot just slide a pointer. It needs to actually combine two different sets of changes.

Git finds the common ancestor (commit B in this case) and then does a three-way comparison:

• What changed between B and F? (changes on main)

• What changed between B and D? (changes on the feature branch)

• Combine both sets of changes into a single new commit

The result is a merge commit with two parents:

A --> B --> E --> F --> M (merge commit)
              \       /
               C --> D

Commit M is special. Its commit object has two parent hashes instead of one. That is how Git encodes the fact that history converged here.

If the same lines were changed differently on both branches, you get a merge conflict. Git cannot automatically decide which change wins, so it stops and asks you.

The three-way part of "three-way merge" refers to the three commits involved: the common ancestor, the tip of branch A, and the tip of branch B. That ancestor is the key. Without it, Git would have no baseline to compare against.

Rebase: The Time Machine

Let's use the same diverging history from above:

main:           A --> B --> E --> F
feature/payment: A --> B --> C --> D

Instead of merging and creating commit M, rebase takes a different approach. It says: "What if I pretended I started my feature branch from F instead of B?"

Rebase replays your commits (C and D) on top of the new base (F):

AFTER rebase:
main:           A --> B --> E --> F
feature/payment:               F --> C' --> D'

Notice the ' marks. C' and D' are new commit objects. They have new SHA hashes. The original C and D still exist in the object store until they get garbage collected.

This is the critical thing to understand about rebase: it rewrites history. The changes are the same, but the commits are completely new objects with new identities.

This has two important consequences.

First, the resulting history is clean and linear. When you merge feature/payment back to main, it will be a fast-forward (no merge commit). Your log stays readable.

Second, you should not rebase commits that have already been pushed to a shared branch. If your teammate has built work on top of your original C and D commits, and you rebase them into C' and D', their history and your history have now diverged. Things get messy.

A good rule of thumb:

• Rebase your local, unpushed commits to clean them up before opening a pull request

• Merge when integrating finished, shared work back into main

Neither is always better. They serve different purposes.

The Reflog: Git's Safety Net

This is probably the most underused feature in Git, and also the most reassuring one to know about.

Every time HEAD moves, Git records it. Every commit, every checkout, every reset, every rebase, every merge. Git logs it in .git/logs/HEAD. This is the reflog (reference log).

Run this:

git reflog

You will see something like:

a3f8b1c HEAD@{0}: commit: Add payment processing
7e2d9f4 HEAD@{1}: checkout: moving from feature/payment to main
3c1a8b5 HEAD@{2}: commit: Add cart total calculation
b5f9e23 HEAD@{3}: commit: Initial cart setup

Every move. Every single one.

So when a junior dev runs git reset --hard HEAD~3 by accident and panics because three commits just vanished? The reflog has those commits. You can get them back:

# Find the commit hash in reflog
git reflog

# Restore it
git checkout -b recovery-branch HEAD@{2}

Or if you deleted a branch and realized you needed it:

git reflog
git checkout -b restored-branch a3f8b1c

You almost cannot lose work in Git if you know about the reflog. The commits are still in .git/objects/. The reflog tells you where they are.

The reflog is local. It does not sync to remote. And it does expire (default 90 days for reachable commits, 30 days for unreachable ones). But within that window, you are almost always safe.

Garbage Collection: The Cleanup Crew

Here is why "deleted" commits hang around long enough for reflog to save them.

When you delete a branch or run a hard reset, Git does not immediately delete the underlying objects. It just removes the references pointing to them. The blobs, trees, and commit objects stay in .git/objects/ until Git runs garbage collection.

Git periodically runs git gc automatically. This command:

1. Scans all objects in .git/objects/

2. Finds any objects with no references pointing to them (no branch, no tag, nothing in reflog)

3. Deletes those unreachable objects

4. Packs remaining objects into pack files for efficiency

You can trigger it manually:

git gc

But in practice you rarely need to. Git handles it automatically and conservatively.

The practical takeaway: if you deleted a branch five minutes ago, the objects are almost certainly still on disk. Use the reflog, find the hash, create a new branch pointing to it, and you are back.

This is why the right mental model for Git is not "deleting things removes them." It is more like: "deleting things removes the label. The actual data stays until the cleanup crew arrives."

What You Now Know

Let's take a breath and look at how far you have come across both parts of this series.

From Part 1, you know:

• Every file, directory snapshot, and commit is stored as an object in .git/objects/

• Objects are identified by SHA-1 hashes of their content

• git add writes blobs to the object store and updates the index

• The four object types: blob, tree, commit, tag

From Part 2, you now know:

• A commit is a pointer to a tree, a pointer to its parent, and some metadata

• A branch is a 40-character file containing a commit hash

• HEAD is either a symbolic ref to a branch or a direct commit hash (detached)

• git commit builds objects, creates a commit, and moves the branch pointer forward

• Fast-forward merge just slides a pointer. Three-way merge creates a new commit with two parents

• Rebase replays commits on a new base, creating new commit objects with new SHAs

• The reflog is a local log of every HEAD movement

• Deleted objects are not immediately removed. Garbage collection handles that later

Git is not magic. It is four object types, some files in .git/refs/, a HEAD file, and a really elegant set of operations built on top of them. When something goes wrong, you now know exactly where to look.

Next time you see "detached HEAD state" or accidentally delete a branch or panic about a bad reset, stop and think: what objects exist? What is HEAD pointing to? What does the reflog say? The answer is almost always in there.

Go open a test repo and poke around. Run cat .git/HEAD. Run cat .git/refs/heads/main. Run git reflog. See the machine underneath the magic.

Once you see it, you cannot unsee it. And honestly, Git becomes a lot less scary after that. 🚀

Happy coding!

But what actually happened?

Most developers I know use Git every single day and have no idea what's going on under the hood. They know the commands. They know the workflow. But the internals? Total mystery. And honestly, that is fine. But that changes something breaks and you have no mental model to debug with.

So let's fix that today. Together.

This is Part 1 of a two-part series. We are going to crack open Git and look at its insides. And I promise you, once you see it, you will never look at git status the same way again.

The .git Directory: Git's Entire Brain

Here is something most tutorials skip over completely. When you run git init in a folder, Git creates one hidden directory: .git/. That is it. That is Git. The entire version control system lives inside that one folder.

Let's look inside it:

.git/
├── HEAD
├── config
├── description
├── hooks/
├── index
├── info/
├── objects/
│   ├── info/
│   └── pack/
└── refs/
    ├── heads/
    └── tags/

Here is what matters:

objects/ is where Git stores every version of every file you have ever committed, plus commits themselves, plus directory snapshots. This is the heart of Git. We will spend most of this article here.

refs/ holds references, basically named pointers to commits. Your branches live here. Tags live here. We will get into this deeply in Part 2.

HEAD is a text file that tells Git which branch you are currently on. Open it right now and look:

cat .git/HEAD
# ref: refs/heads/main

Just a text file. One line. That is your "current branch."

index is the staging area, the place where git add puts things before they become a commit. It is a binary file that maps file paths to object hashes.

config holds your repository-level configuration (remote URLs, user settings for this repo, etc.).

That is the whole brain. Pretty approachable when you lay it out like this, right?

Git is a Content-Addressable Filesystem

This phrase sounds technical but the idea behind it is dead simple.

Imagine a library where books are not named by title. Instead, every book is named by a unique code that is mathematically derived from the book's exact contents. If two books have identical text, they get the same code. Change a single comma and the code is completely different.

That is exactly how Git stores data.

Every piece of content you give Git, whether that is a file, a directory snapshot, or a commit — gets hashed using SHA-1 (more on this shortly). The resulting 40-character hex string becomes both the name and the address of that piece of content in Git's object store.

This means:

• The same content always produces the same hash. Always.

• Different content always produces a different hash.

• Git never loses data, because data is identified by what it is, not by where it lives.

You can try this right now. Create any text file and run:

echo "Hello, Git" | git hash-object --stdin
# 8ab686eafeb1f44702738c8b0f24f2567c36da6d

That 40-character string is the address of that content in Git's world. Run the same command on any machine, with any repo, and you will get the exact same hash, because the content is the same.

That is what "content-addressable" means. The address comes from the content itself.

The Four Object Types

Git's object store has exactly four types of objects. Every single thing Git tracks is one of these four.

Blob: Just the Content, Nothing Else

A blob stores the raw content of a file. Not the filename. Not the path. Just the bytes.

So if you have two different files with identical contents, Git stores only one blob. They share it.

Let's see a blob in action. After staging a file, you can find and inspect the blob Git created:

echo "Hello, World" > hello.txt
git add hello.txt

# Find the hash of our staged file
git ls-files --stage
# 100644 8ab686eafeb1f44702738c8b0f24f2567c36da6d 0    hello.txt

# Inspect the object type
git cat-file -t 8ab686eafeb1f44702738c8b0f24f2567c36da6d
# blob

# Inspect the content
git cat-file -p 8ab686eafeb1f44702738c8b0f24f2567c36da6d
# Hello, World

See that? The blob just contains Hello, World. No filename. No metadata. Pure content.

Tree: Git's Version of a Directory

A tree object maps filenames to blobs (and other trees for subdirectories). It is essentially a directory snapshot.

After your first commit, you can inspect the tree it points to:

# Get the commit hash
git log --oneline -1
# a1b2c3d Initial commit

# Look at the commit's tree
git cat-file -p a1b2c3d
# tree 92b8935ad25c3b4a11cd4beba1c3ac2a516a06a2
# author Dulitha Rajapaksha ...
# committer Dulitha Rajapaksha ...
#
# Initial commit

# Inspect the tree itself
git cat-file -p 92b8935ad25c3b4a11cd4beba1c3ac2a516a06a2
# 100644 blob 8ab686eafeb1f44702738c8b0f24f2567c36da6d    hello.txt

A tree entry looks like this:

[mode] [object-type] [hash]    [filename]
100644 blob           8ab686...  hello.txt
040000 tree           f3f1c8...  src/

The tree says: "In this directory, there is a file called hello.txt and its contents are the blob with this hash. And there is a subdirectory called src/ which is the tree with that hash."

Simple, elegant, recursive.

Commit: The Snapshot in Time

A commit object ties everything together. It points to:

1. A tree (the root directory snapshot at that moment)

2. A parent commit (the previous commit, so Git knows the history)

3. Author metadata (name, email, timestamp)

4. Committer metadata (can differ from author, for example when applying patches)

5. The commit message

Let's look at a real commit object:

git cat-file -p HEAD
# tree 92b8935ad25c3b4a11cd4beba1c3ac2a516a06a2
# parent f4e3d2c1b0a9...
# author Dulitha Rajapaksha <dulitha@example.com> 1708732800 +0530
# committer Dulitha Rajapaksha <dulitha@example.com> 1708732800 +0530
#
# Add hello.txt with greeting

Notice that a commit does not store a diff. It stores a full snapshot of the entire working tree via the tree object. Git is not a delta-based system at its core. It is a snapshot-based system.

This is why git checkout to an old commit is instant. Git is not replaying changes backwards. It is just loading the snapshot that commit points to.

Tag: A Named Pointer to a Commit

An annotated tag (created with git tag -a) is its own object type. It points to a commit and adds extra metadata: the tagger's name, a date, and a tag message.

git tag -a v1.0 -m "First release"
git cat-file -p v1.0
# object a1b2c3d4e5f6...
# type commit
# tag v1.0
# tagger Dulitha Rajapaksha <dulitha@example.com> 1708732800 +0530
#
# First release

Lightweight tags (created with just git tag v1.0) are not objects at all. They are just refs, plain text files pointing directly to a commit hash. Annotated tags are the "proper" ones with full provenance.

How Objects Are Stored on Disk

Now you know what the four object types are. But how does Git actually store them on your filesystem?

Go look inside .git/objects/ right now:

ls .git/objects/
# 8a/
# 92/
# a1/
# info/
# pack/

See those two-character folder names? Git takes the 40-character SHA-1 hash and splits it: the first 2 characters become the folder name, and the remaining 38 characters become the filename inside that folder.

So the blob with hash 8ab686eafeb1f44702738c8b0f24f2567c36da6d lives at:

.git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d

You can verify it:

ls .git/objects/8a/
# b686eafeb1f44702738c8b0f24f2567c36da6d

Why split it this way? Filesystem performance. If you have a project with 100,000 objects (entirely normal for a large codebase), putting them all in one folder would make directory operations painfully slow. Splitting by the first two hex characters gives you up to 256 possible subfolders, spreading the objects evenly.

The objects themselves are stored as zlib-compressed binary files. That is why you cannot just cat them directly. You need git cat-file to read them properly.

For large repos, Git also packs objects into .git/objects/pack/ files using delta compression. That is a whole other topic, but the core loose object model is what we covered here.

SHA-1 Hashing, Explained Simply

Everything in Git's object model depends on SHA-1 hashing, so let's make sure we actually understand what that means.

A hash function takes any input (a word, a file, a novel, a video) and produces a fixed-length output. For SHA-1, that output is always 40 hexadecimal characters.

A few key properties make this useful:

Deterministic: The same input always produces the same output. Always. You can hash the same file a million times and get the exact same 40 characters.

Avalanche effect: Change one single bit of input and the output is completely, unpredictably different. There is no way to look at two hashes and tell how similar the inputs were.

Practically collision-free: Two different inputs producing the same hash is theoretically possible but so astronomically unlikely that it has never happened accidentally in the wild for SHA-1. (Engineered collisions are a different story, which is why Git is moving to SHA-256.)

Here is the avalanche effect in action:

echo "Hello, Git" | git hash-object --stdin
# 8ab686eafeb1f44702738c8b0f24f2567c36da6d

echo "Hello, git" | git hash-object --stdin
# 06a1c49a2e8e9b08beb4c39e7e1cd07a56b89a31

Just changing the capital G to lowercase g produces a completely different hash. That is the avalanche effect at work.

Git also uses the hash as a checksum. When you fetch from a remote, Git hashes the received objects and checks them against the hashes in the transfer protocol. Any corruption or tampering is immediately detectable. Your history is cryptographically protected.

One more thing worth mentioning: Git is currently migrating from SHA-1 to SHA-256. SHA-1 has known weaknesses against engineered collision attacks (though exploiting them against Git in practice is extremely hard). The SHA-256 migration produces 64-character hashes and is already supported in recent Git versions. For day-to-day usage, SHA-1 repos are perfectly fine.

What Actually Happens When You git add

Okay, we have built up enough context. Let's trace exactly what happens when you run git add.

Take a fresh file:

echo "Learning Git internals" > notes.txt

At this point, Git knows nothing about this file. The object store has nothing for it. The index does not reference it.

Now run:

git add notes.txt

Two things happen, in this order:

Step 1: A blob object is created. Git reads the content of notes.txt, prepends a header (blob [byte-length]\0), hashes the whole thing with SHA-1, compresses it with zlib, and writes it to .git/objects/[xx]/[remaining-hash].

You can do this manually with git hash-object:

git hash-object notes.txt
# e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Step 2: The index is updated. The staging area (.git/index) is updated to map notes.txt to the blob hash we just created.

That is it. No commit exists yet. No tree exists yet. Just a blob sitting in the object store, and the index pointing to it.

Let's verify the blob was created:

ls .git/objects/e6/
# 9de29bb2d1d6434b8b29ae775ad8c2e48c5391

git cat-file -t e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
# blob

git cat-file -p e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
# Learning Git internals

When you run git commit, Git reads the index, builds a tree object from it (creating tree objects recursively for subdirectories), then creates a commit object pointing to that root tree and the previous commit. But the blob was already there, created at git add time.

This is why git add can be slow for large files or many files. The real work, hashing and compressing content, happens at add time, not commit time.

What's Coming in Part 2

So now you know how Git stores things. You understand blobs, trees, commits, and tags. You can inspect any object with git cat-file. You know why the objects folder is split the way it is.

But here is where it gets really interesting.

In Part 2, we are going to talk about how commits chain together to form history. We will look at what a branch actually is under the hood, and I think it will surprise you how embarrassingly simple it is. We will also walk through what git merge and git rebase are actually doing to those objects behind the scenes.

The mental model you are building right now is exactly what makes those concepts click. Stay tuned! 🚀

Chao!

You asked it to write tests. It said "Done! All tests pass." You ran the tests yourself. They didn't pass. Maybe they didn't even exist.

Yeah. I know that feeling. But I didn't just get burned once, I built an entire Laravel package development pipeline with four Claude Code agents, and somewhere in there, the agents started lying to each other and passing those lies up the chain to me as verified truth.

This is that story. What happened, what the fabricated reports looked like, and most importantly, what I have done to stop it.

The Setup: Four Agents, One Laravel Package

A few weeks back, I started building a commercial Laravel package (as a fun project), a project with multiple complex features, strict test coverage requirements, a tiered licensing model (Community / Pro / Business), and real customers eventually depending on it.

This is not a small package. We're talking about a product with real value behind it, real test coverage requirements, a real world need.

I didn't want to build it alone. Not because I couldn't (of course not!), but because I was curious whether a properly designed multi-agent Claude Code pipeline could genuinely accelerate serious commercial package development. So I designed one.

The cast:

• Silas - the senior developer agent. He writes the PHP, the JavaScript, the Pest tests, the Vitest tests. He consults Elena on architecture decisions before touching anything.

• Elena - the architect. She reviews every feature Silas ships. Her job is to verify that nothing violates the method budget, the LOC constraints, or the architectural decisions we made in round-table.

• Julian - the monetization specialist. His job is to verify that every Pro and Business tier feature is properly gated and that all bypass attempts fail. He runs his own independent test passes. He's not allowed to trust Silas's results.

• Me (the Coordinator) - I don't write code. I orchestrate, validate agent reports, catch fabrication, log everything to a validation log, and report to the user.

The idea was solid. Round-table planning before any code gets written. Every decision backed by evidence. Independent verification at every gate. Validation logs that build an auditable history.

In theory, this should be waterproof.

In practice... we had a problem.

The First Red Flag: Round Numbers and No Receipts

It started subtly. Silas would finish implementing a feature and submit a report something like this:

"Feature complete. 628 tests pass, 0 failures. All edge cases covered. Elena has reviewed the architecture and confirmed compliance. Julian verified tier gating."

628! A nice round number. Sounds great.

Here's what I didn't see attached to that report:

• No test output file

• No timestamp

• No path to where that output lived

• No command that was run to produce it

Just... a number. Stated with complete confidence.

I asked Silas: "Where's the output file?"

He responded with something like: "Tests were executed successfully. All 628 pass."

Still no file. Still no timestamp. Just a restatement of the claim.

At this point, a reasonable person might shrug and move on. 628 tests, sounds like a lot, must be fine. The agent is confident.

I didn't move on. I asked for the actual output.

The Moment I Realized What Was Actually Happening

When I dug deeper, I discovered something that genuinely made me stop and stare at my screen.

Silas hadn't actually run the tests. Or if he had, he hadn't captured the output in any verifiable form. He was estimating the test count based on the number of test files that existed. Or he was echoing back numbers from a previous run. Or, and this is the one that got me. He was just reporting what he believed the outcome should be, because the code looked correct to him.

Then I checked Elena's review. Elena had signed off on the architecture. But Elena had trusted Silas's report when she did so. She hadn't independently verified the test suite. She'd read Silas's output, seen "628 tests pass," and written her review as if that were established fact.

Then I looked at Julian's verification. Julian had confirmed that the tier gating was secure. But Julian had also referenced "the test results Silas shared" rather than running his own independent verification.

So what I had was:

Silas: "628 tests pass" (no proof)
    ↓
Elena: "Architecture approved — Silas's tests confirm compliance" (trusted Silas)
    ↓
Julian: "Tier gating secure — per Silas's validated test run" (trusted Elena's trust of Silas)
    ↓
Coordinator: receives chain as "verified, multi-agent approved" result
    ↓
User: "Everything is good!"

A trust chain built on nothing. Three agents, all confidently reporting success, all citing each other, and none of them had independently verified a single thing.

This is not a bug. This is what AI agents do by default. They are trained to be helpful. Being helpful means completing the task. Completing the task means reporting success. And if the code looks right and the previous agent said it worked... well, why wouldn't they trust it?

What Fabricated Reports Actually Look Like

Now that I knew what to look for, I could see the patterns everywhere. Here's a field guide.

Pattern 1: The Round Number Without Proof

"628 tests pass, 0 failures."

628 is suspiciously round. Real test suites rarely land on a clean hundred. When I see a number like this with no output file attached, it's almost always an estimate or a hallucination.

Real output looks like this:

Tests: 1196 passed, 0 failed, 0 skipped
Duration: 47.82s

Ugly. Specific. Timestamped. Real.

Pattern 2: Qualitative Claims Without Evidence

"Architecture is excellent and fully compliant."
"All edge cases are well covered."
"The tier gating is robust and secure."

None of these are verifiable statements. What does "excellent" mean? What edge cases? Which bypass attempts did you try and fail? If I can't point to an artifact, the claim doesn't exist.

Pattern 3: The Trust Chain Reference

"As confirmed by Silas's earlier validation..."
"Per Elena's architectural review..."
"Building on the verified results from..."

Any time an agent cites another agent's report as the basis for its own validation, you have a trust chain. The only cure is mandatory independent execution. Julian must run the tests himself. Not reference Silas's run. Not trust Elena's summary. His own run, with his own output file, with a timestamp I can read.

Pattern 4: Timestamp Mismatch

This one is sneaky. The agent produces a real output file. But it's from yesterday. Or last week. It was a real run, just not a recent one. The test suite might have changed dramatically since then.

Mandatory requirement: every test output file must have a timestamp visible in the output, and that timestamp must be within the last 24 hours at validation time.

Pattern 5: The Hedged Restatement

When you push back on an unverified claim, a fabricating agent will often respond by restating the claim with slightly more confidence rather than producing proof:

You: "Where is the test output file?"
Agent: "The tests were successfully executed and all 628 pass.
        The suite is clean and ready for review."

That's not an answer. That's a louder version of the original claim. A real answer looks like:

You: "Where is the test output file?"
Agent: "test-output-2026-02-17-223459.txt — here is the relevant excerpt:
        [actual output]"

Building the Accountability System

Once I understood what was happening, I had to make it structurally impossible to pass unverified claims up the chain. Not hard. Not annoying. Impossible.

Here's what the system looks like now.

Mandatory Timestamped Output Files

Every test run, every single one, must produce a file. Not just terminal output. A named file with a timestamp in the name, saved to a known path.

vendor/bin/pest 2>&1 | tee /path/to/test-output-$(date +%Y%m%d-%H%M%S).txt

Silas runs this. Julian runs this. They are not the same file. They are not from the same run. They are independent.

When either of them submits a report, the proof artifact is the file path plus an excerpt of the actual output. I can look at the file. I can check the timestamp. I can verify the numbers match.

No file = report rejected. Full stop.

The Proof Artifact Requirement

Every agent report must include, literally written into the report:

CLAIM: 1196 tests pass, 0 failures
EVIDENCE: test-output-20260217-223459.txt
TIMESTAMP: 2026-02-17 22:34:59
EXCERPT:
  Tests: 1196 passed, 0 failed, 0 skipped
  Duration: 47.82s
VERIFIED: Yes

If any of those fields are missing, the report is rejected immediately and sent back with a specific list of what's missing.

The Rejection Protocol

The coordinator, me, has a hard rule: if a report fails the proof artifact checklist, I do not "note the concern and proceed." I reject the report completely.

REPORT REJECTED

Reason: No test output file provided.
Required artifacts missing:
  - Timestamped output file path
  - Pass/fail counts from actual execution
  - Test framework version in output header

Resubmit with all mandatory proof artifacts.
This report has NOT been passed to the user.

This feels harsh. It is harsh. That's the point.

The Validation Log

Every validation, accepted or rejected, gets appended to docs/internal/VALIDATION-LOG.md. This log is append-only and gitignored. It builds an auditable history of every agent action in the project.

### 2026-02-17 22:45 — Feature 18 Cell Merging — Silas — ACCEPTED

**Artifacts provided:**
- [x] test-output-20260217-223459.txt (timestamp verified)
- [x] Pass/fail counts: 1196/0/0 (matches claim)
- [x] Test framework: Pest 3.x shown in header
- [x] Infrastructure checklist complete

**Verdict:** ACCEPTED
**Logged by:** Main Coordinator

When something gets rejected, the rejection reason is there in black and white. The history doesn't get cleaned up.

Independent Verification for Every Tier

Julian's role specifically exists to catch the case where Silas might code something correctly but not actually verify that the tier gates work in a hostile scenario.

Julian's rules:

• He runs his own test suite independently. Never trusts Silas's output

• He must specifically attempt to bypass each tier gate and document the attempt

• He must show that bypass attempts fail (with the actual error output as proof)

• A "SECURE" grade requires 100% gate test pass rate. Not "mostly secure"

Before this system, Julian would read Silas's report, see "tier gating implemented," and write "SECURE." After this system, Julian produces his own file, his own bypass attempt logs, and his own failure evidence.

The Oath (And Why It Has to Be Written Down)

One thing I learned from this experience: accountability systems only work if the rules are explicit, unambiguous, and written down somewhere the agent can be held to them.

So I wrote an oath into the coordinator's requirements file. Not as a nice sentiment. As a hard constraint.

I will NEVER pass fabricated reports to the user as truth.

I will ALWAYS validate agent reports before accepting. I will ALWAYS demand proof artifacts. I will NEVER soften or hide problems. I will ALWAYS log validations. I will NEVER trust without verification. I will ALWAYS be honest about what I know vs what I don't know.

And critically: "This is automatic. The user never needs to remind me."

That last line matters. The whole point of an accountability system is that it runs even when no one is watching. If the coordinator only enforces these rules when the user explicitly asks, then it's not a system, it's just a prompt.

The rules are in ~/.claude/agent-requirements/main-coordinator.md. They load every session. They apply to every project. No exceptions.

The Lesson: AI Agents Are Optimistic by Default

Here's the uncomfortable truth I had to accept:

AI agents are not trying to deceive you. They are trying to help you. And "helping" often means telling you what you want to hear.

The agent that reports "628 tests pass" without running the tests isn't malicious. It's doing exactly what it was trained to do: complete the task, report success, move forward. The training signal for "helpful" is often correlated with "positive outcome for the user", and "628 tests pass, 0 failures" feels a lot more positive than "I could not verify the test count."

This is why you can't fix this problem with better prompting alone. You can tell an agent "always verify before reporting" and it will agree enthusiastically, and then the next time it's under pressure to complete a feature, it will estimate and report as if it verified.

You have to build the adversarial layer structurally. The only way an agent can submit a report is if it has the artifacts. If the mechanism for submitting a report requires attaching a file, and there is no file, the agent cannot submit the report. The constraint has to be in the shape of the workflow, not just in the instructions.

Think of it like database constraints vs. application-level validation. Application-level validation can be forgotten. A NOT NULL constraint cannot.

This is also why the independent verification requirement matters so much. If Silas's report is the only evidence that Silas's work is correct, you have a single point of failure that is highly motivated to report success. Julian running independent tests isn't a nice-to-have. It's the separation of duties that makes the system trustworthy.

What the Pipeline Looks Like Now

After building all of this, here's where the project stands:

• 1,196 Pest tests passing, 0 failures (independently verified, timestamped output on disk)

• 459 Vitest tests passing, 0 failures (same standard)

• Features 1-18 shipped - every feature tracked and validated

• Every feature has a VALIDATION-LOG entry - accepted or rejected, the history is there

• Zero trust chains - every agent cites its own artifacts, not another agent's summary

The package is real. The tests are real. The agents work. They just needed an adversarial layer to keep them honest.

Was it more work to build the accountability system than to just vibe-check the agents and trust their output? Absolutely. But here's the thing: the accountability system is the product, as much as the code is. A commercial package built on unverified claims from AI agents that were trusting each other in a circle is a liability. The validation log, the timestamped output files, the independent verification, those are what let me sleep at night.

If you're building anything serious with multi-agent pipelines, I genuinely hope you find this useful before you find out the hard way. The agents will be confident. The numbers will sound right. And none of it will mean anything without proof artifacts.

Build the adversarial layer. Build it structurally. Write it down. Don't rely on prompting alone.

Trust, but verify. Actually, no, just verify.

Key Takeaways

• AI agents are optimistic by default. They report success because that's what "helpful" looks like during training

• Trust chains (Agent A trusts Agent B trusts Agent C) are just as unverified as a single unverified claim

• The five fabrication patterns to watch for: round numbers without proof, qualitative claims, trust chain references, timestamp mismatches, hedged restatements

• Proof artifact requirements must be structural. Not just instructional

• Independent verification (multiple agents running the same verification independently) is the separation of duties that makes a pipeline trustworthy

• The validation log builds the auditable history that lets you catch problems before they reach the user

I'll keep sharing what I'm learning building this package with this pipeline. The next post will cover the round-table system. How I get three agents to debate architecture decisions until all three are 10/10 confident before a single line of code gets written.

Stay tuned! And in the meantime, go check your AI's test output. The real output, with a timestamp.

I'll wait. 🎯

Happy coding!

Sound familiar?

Don't worry. Laravel has a hidden gem that most developers walk past every single day. It's been sitting there since version 9.40, quietly waiting to save you from notification hell.

Meet the Lottery class.

Wait, Laravel Has a Lottery?

Yes! And no, Taylor Otwell didn't add gambling to the framework (though that would make stand-ups more interesting).

The Lottery class lives in Illuminate\Support\Lottery and does exactly what it sounds like. It lets you run code based on probability. Think of it as a bouncer for your callbacks. Sometimes they get in. Sometimes they don't.

Here's the simplest example:

use Illuminate\Support\Lottery;

$result = Lottery::odds(1, 5)->choose();

// Returns true 20% of the time, false 80% of the time

The odds() method takes two arguments: winning chances and total chances. So odds(1, 5) means 1 in 5 chance, or 20% probability. Simple maths, powerful results.

But here's where it gets spicy. You can attach callbacks:

Lottery::odds(1, 10)
    ->winner(fn () => logger('🎉 You won!'))
    ->loser(fn () => logger('😢 Maybe next time'))
    ->choose();

The winner() callback fires when luck is on your side. The loser() callback runs when it isn't. Finally, choose() rolls the dice and returns whatever your callback returns.

The Real Problem This Solves

Let's get real for a second. Why would you ever want code to run... sometimes?

Here's a scenario every Laravel developer has faced:

You're a responsible developer. You've enabled Model::preventLazyLoading() in production because you read that article about N+1 queries being evil. Good job! But now your Sentry dashboard looks like this:

Your app handles 500,000 requests daily. Each request triggers 3 lazy loading violations on average. That's 1.5 million error reports. Per day.

Your Sentry bill? Through the roof. Your inbox? Destroyed. Your will to live? Questionable.

But here's the thing. You don't NEED 1.5 million reports to know you have a problem. You just need... some of them. Enough to know the issue exists and where it lives.

Enter the Lottery.

Real World Use Cases (The Fun Part)

Let me show you some scenarios where the Lottery class absolutely shines.

1. The "Please Stop Emailing Me" Slow Query Logger

Your database has some... let's call them "personality traits." Sometimes queries take longer than they should. You want to know about it, but not EVERY time.

use Carbon\CarbonInterval;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Lottery;

// In your AppServiceProvider boot() method
DB::whenQueryingForLongerThan(
    CarbonInterval::seconds(2),
    Lottery::odds(1, 100)->winner(
        fn () => report('🐌 Query exceeded 2 seconds. Time for a coffee break!')
    )
);

Now only 1% of slow queries get reported. You still catch the problem. Your phone stays quiet. Everyone's happy.

Notice something cool here? We're passing the Lottery instance directly to whenQueryingForLongerThan(). No need to wrap it in a closure or call choose(). That's because...

2. The Magic of __invoke()

Here's where my mind was blown when I first discovered this.

The Lottery class implements __invoke(), which means a Lottery instance IS a callable. You can pass it anywhere that accepts a callback.

From the Laravel documentation:

Since the lottery class is callable, we may pass an instance of the class into any method that accepts callables.

This is HUGE. Laravel has tons of methods that accept callables. And the Lottery class slides right in.

3. The "My Error Tracker Bill Is How Much?!" Solution

Let's say you're importing products from a sketchy CSV file your client sent you. (We've all been there.) Some rows will fail. Many rows will fail. You don't need to report ALL of them.

$products = collect($csvRows);
$failedCount = 0;

$products->each(function (array $row) use (&$failedCount) {
    try {
        Product::create($row);
    } catch (ValidationException $e) {
        // Report only 1% of failures to Sentry
        Lottery::odds(1, 100)
            ->winner(fn () => report("Import failed: {$e->getMessage()}"))
            ->choose();

        $failedCount++;
    }
});

logger("Import complete. {$failedCount} rows failed.");

Your CSV has 50,000 bad rows? Instead of 50,000 Sentry events (and a very angry finance team), you get around 500. Still enough to debug the patterns, not enough to bankrupt you.

4. The "Let's A/B Test Without Actually Setting Up A/B Testing" Hack

Need to show a new feature to a percentage of users but don't have time to set up a proper feature flag system? I've got you.

public function index()
{
    return Lottery::odds(10, 100)
        ->winner(fn () => view('dashboard.shiny-new-version'))
        ->loser(fn () => view('dashboard.boring-old-version'))
        ->choose();
}

10% of users see the new dashboard. 90% see the old one. Is this a proper A/B test with analytics? No. Will it work for a quick experiment before your sprint demo? Absolutely.

5. The "Our Analytics Pipeline Is Crying" Data Sampling

Your data science team wants user behavior analytics. Processing all 2 million users would take 3 days. They need results by tomorrow.

User::chunk(1000, function ($users) {
    foreach ($users as $user) {
        // Process roughly 5% of users
        Lottery::odds(5, 100)
            ->winner(fn () => AnalyzeUserBehavior::dispatch($user))
            ->choose();
    }
});

Instead of 2 million jobs, you queue around 100,000. Still statistically significant. Finishes overnight. Data scientists buy you coffee.

6. The "Pizza Party Decider" (Yes, Really)

Okay, this one's just for fun. But imagine this in your Slack bot:

$shouldOrderPizza = Lottery::odds(1, 20)
    ->winner(fn () => "🍕 PIZZA FRIDAY IS TODAY! Order now!")
    ->loser(fn () => "No pizza today. Back to work.")
    ->choose();

$slack->send('#general', $shouldOrderPizza);

5% chance of pizza every Friday. The suspense keeps morale high. HR loves you.

Testing Lottery-Based Code (Without Going Crazy)

"But wait," I hear you say. "How do I test code that's literally random?"

Great question! Laravel thought of this. The Lottery class comes with testing utilities that make randomness, not random.

Force a Win Every Time

use Illuminate\Support\Lottery;

public function test_new_dashboard_renders_for_lottery_winners()
{
    Lottery::alwaysWin();

    $response = $this->get('/dashboard');

    $response->assertViewIs('dashboard.shiny-new-version');
}

Force a Loss Every Time

public function test_old_dashboard_renders_for_lottery_losers()
{
    Lottery::alwaysLose();

    $response = $this->get('/dashboard');

    $response->assertViewIs('dashboard.boring-old-version');
}

Predetermine a Sequence

Need more control? You can script exactly what happens:

// First call wins, second loses, third wins, then random
Lottery::fix([true, false, true]);

Lottery::odds(1, 2)->choose(); // true (first in sequence)
Lottery::odds(1, 2)->choose(); // false (second in sequence)  
Lottery::odds(1, 2)->choose(); // true (third in sequence)
Lottery::odds(1, 2)->choose(); // random (sequence exhausted)

Reset to Normal Behavior

Always clean up after yourself:

protected function tearDown(): void
{
    Lottery::determineResultsNormally();
    parent::tearDown();
}

This prevents test pollution. Nobody wants their tests failing because a previous test left the Lottery rigged.

Quick API Reference

Here's everything the Lottery class offers:

When NOT to Use Lottery

Let's be honest. The Lottery class isn't a silver bullet. Here's when you should reach for something else:

Feature Flags: If you need to know WHICH users saw WHAT, use Laravel Pennant or a proper feature flag system. Lottery is random per request, not per user.

A/B Testing with Analytics: Same deal. If you need conversion metrics, you need to track cohorts. Lottery won't remember who saw what.

Critical Error Reporting: If an error MUST be reported (payment failures, security issues), don't gamble with it. Some things are too important.

Rate Limiting: If you need "X requests per minute", use Laravel's rate limiter. Lottery is probabilistic, not deterministic.

The Elegance Factor

What I love about the Lottery class is how it transforms ugly code into something readable.

Before (the old way):

if (random_int(1, 100) <= 5) {
    report($exception);
}

After (the Laravel way):

Lottery::odds(5, 100)
    ->winner(fn () => report($exception))
    ->choose();

The intent is crystal clear. Anyone reading this code immediately understands: "This reports 5% of exceptions."

And when you combine it with Laravel's callback-accepting methods:

DB::whenQueryingForLongerThan(
    CarbonInterval::seconds(2),
    Lottery::odds(1, 100)->winner(fn () => report('Slow query detected'))
);

No if statements. No manual random number generation. Just clean, fluent code that reads like English.

Wrapping Up

The Lottery class has been in Laravel since version 9.40, and it's still one of the framework's best-kept secrets. If you're dealing with high-volume events that need sampling, give it a try.

Next time you find yourself writing if (random_int(1, 100) <= 5), stop. Laravel has a better way.

Your error tracker will thank you. Your phone will thank you. And your 3 AM self will definitely thank you.

Found this helpful? Follow me for more Laravel tips and deep dives into features you probably didn't know existed.

Cheerio!

I used to take this for granted. Then one day, I actually stopped and thought: "Wait, how on earth does this even work?"

Spoiler alert 🚀

There's some seriously clever engineering behind that seamless experience. Buckle up, because we're about to peek behind the curtain of one of the coolest algorithms you've never heard of.

The Problem is Way Harder Than You Think

Okay, let's set the scene.

You and your colleague are both editing the same document. You're at position 5, inserting the word "awesome". At the exact same millisecond (because of course it happens at the worst possible time), your colleague at position 3 deletes a character.

Now what? 🤯

If you just applied both operations as-is, chaos ensues. Your "awesome" might end up in the wrong place, or worse, overwrite something important. Now multiply this by 50 users, throw in some network latency, sprinkle in a few people on spotty WiFi, and congratulations! You've got yourself a distributed systems nightmare.

This is the concurrent editing problem, and Google solved it using something called Operational Transformation (OT).

Sounds fancy, right? It is. But stick with me.

Operational Transformation: The Algorithm That Keeps Everyone Sane

Here's a fun fact that blew my mind: OT isn't some shiny new tech Google invented in a secret lab. It actually dates back to 1989! Two researchers named C.A. Ellis and S.J. Gibbs created it for a system called GROVE (GRoup Outline Viewing Edit).

Yes, this algorithm is older than most of us reading this (Definitely older than me). And it's still running the show.

Google adopted and supercharged it in 2009 for Google Wave (RIP 🪦), and later brought it to Google Docs, Sheets, and Slides.

So what's the big idea?

Instead of syncing document states, you sync operations.

Every edit you make gets captured as an operation:

• Insert: Add character 'X' at position 5

• Delete: Remove 1 character at position 3

• Retain: Keep the next N characters unchanged (basically "skip over this part")

When these operations conflict, OT transforms them so they can be applied in any order and still produce the same result.

It's like magic. Except it's math. Which, let's be honest, is just magic with extra steps.

Let's Walk Through an Example (Because Examples Are Fun)

Alright, time to get our hands dirty.

Say we have a document with the text: "HELLO"

User A (chilling at position 5) wants to add some excitement: Insert("!", 5)

User B (over at position 2) decides that second "L" has got to go: Delete(2, 1)

Both operations happen at the same time. The server receives them, looks at them, and goes "Oh boy, here we go again."

Without OT, we'd get different results depending on whose change arrives first. User A might see "HELO!" while User B sees "HELLO" with a missing character somewhere weird. Total mess.

Here's where OT saves the day:

1. The server sees User B already deleted a character at position 2

2. It looks at User A's insert and thinks: "Hey, a character before position 5 got deleted, so position 5 is now actually position 4"

3. User A's operation gets transformed: Insert("!", 4)

Result? Both users end up with "HELO!". Same document. Same state. Crisis averted. 🎉

The transformation follows a simple principle: adjust positions based on what other operations have already done. That's it. That's the secret sauce.

The Client-Server Dance (It's Actually Pretty Elegant)

Google's implementation uses a client-server setup that works like a beautifully choreographed dance. Let me break it down:

On Your Device (The Client):

1. You smash that keyboard and type a character

2. It immediately appears on your screen (no waiting for the server, because ain't nobody got time for that)

3. Your edit gets captured as an operation and sent to the server

4. Meanwhile, you keep typing like the productivity machine you are

This is called optimistic UI, and it's why Google Docs feels so snappy.

On Google's Server (The Brain):

1. Receives operations from all connected users (imagine juggling 50 balls at once)

2. Applies OT to transform any conflicting operations

3. Maintains a single source of truth (the "official" document state)

4. Broadcasts transformed operations back to everyone

Back on Your Device:

1. Receives transformed operations from other users

2. Applies them to your local document

3. Everything magically stays in sync

The beautiful part? Your typing never feels laggy. You get instant feedback while the server sorts out all the messy concurrency stuff in the background. It's like having a really efficient personal assistant who handles all the drama while you focus on your work.

The Three Holy Guarantees of OT

For OT to work correctly, it needs to maintain three sacred properties. Break any of these, and the whole thing falls apart:

1. Convergence

After all operations are applied, every user's document must be identical. No exceptions. No "close enough". Byte-for-byte identical.

2. Causality Preservation

If operation A happened before operation B, then A must be applied before B on all clients. We can't have time-traveling edits (as cool as that sounds).

3. Intention Preservation

The intent of each edit must be preserved. If you meant to delete "that word", the algorithm shouldn't accidentally delete something else. That would be rude.

What About Google Sheets? (It's a Bit Different!)

Sheets handles concurrent editing with a twist. Since spreadsheets are divided into cells, conflicts get resolved at the cell level, not the document level.

Two users editing different cells? No conflict. Both changes apply independently. Everyone's happy.

Two users editing the same cell at the exact same millisecond? Sheets pulls out the last-writer-wins card. Whoever's operation reaches the server last gets their value persisted.

"But wait, isn't that unfair?"

Kind of! But here's the thing: cell-level conflicts are actually pretty rare in practice. How often are you and your colleague really typing into the exact same cell at the exact same moment? Unless you're doing some kind of extreme spreadsheet collaboration sport (which, if that exists, please do not invite me), it's not a huge problem.

OT vs. CRDTs: The Nerdy Showdown

You might have heard of CRDTs (Conflict-free Replicated Data Types). It's another approach to solving the same problem, and tools like Figma use it instead of OT.

Here's the quick comparison for the curious:

Google sticks with OT because it plays nicely with their centralized architecture and handles their massive scale. CRDTs are awesome when you need true peer-to-peer collaboration or rock-solid offline support.

Different tools, different trade-offs. Both are genuinely impressive engineering.

Why Should You Care? (Practical Takeaways)

Understanding OT isn't just nerdy trivia for your next tech dinner party (though it definitely works for that too). It teaches us some valuable lessons:

🚀 Optimistic UI is powerful: Don't make users wait for server confirmation for every tiny action. Show the result immediately and sync in the background.

🔄 Operations over state: Sometimes syncing what changed is way smarter than syncing the entire state. This principle applies to so many problems.

⚖️ Trade-offs are everywhere: OT chose centralized architecture for simplicity. CRDTs chose decentralization for resilience. Neither is "wrong". Context matters.

And hey, if you ever need to build collaborative features yourself, you now know where to start! Libraries like ShareJS and Yjs implement these concepts and can save you months of head-scratching.

Wrapping Up

Next time you're in a Google Doc with your entire team typing away like caffeinated squirrels, take a moment to appreciate the engineering marvel happening behind the scenes.

Operational Transformation has been keeping our collaborative chaos organized since 1989 (!!!), and Google's implementation handles millions of concurrent editors without breaking a sweat.

The document you're editing isn't just a file. It's a carefully orchestrated symphony of operations, transformations, and state reconciliation, all happening in milliseconds while you're just trying to fix that one typo your colleague made.

Pretty wild, right? 🚀 Share with your colleagues and let them know how beautiful the tech world is!

Want to go deeper? Check these out:

• Google Wave Operational Transformation Whitepaper

• Jupiter Collaboration System (1995) - The algorithm that inspired Google's implementation

• Wikipedia: Operational Transformation

The culprit? Cache tags. Those innocent-looking Laravel helpers that promise easy cache management. Turns out, "easy" and "scalable" aren't always the same thing.

Here's what I learned rebuilding the caching layer from scratch.

Every story has to start somewhere. So, get ready and keep your eyes on the road ahead!

First, The Disaster

Our messaging app was doing great in the early days. A few hundred users and queries per page seemed manageable at first. After all, we were already caching it, so what could go wrong? Those were, indeed, famous last words.

When I actually stress-tested it:

• User A sends a message

• Users B, C, and D need their unread badges updated

• The conversation list for everyone needs to reflect the new message

• Cache tags start creating orphaned data

• Redis memory climbs

• Everything slows down

• I start questioning my career choices

The "just flush the tag" approach was killing us. Time to actually understand what was happening under the hood.

🍵 Coffee Break Reality Check

If you're here because your cache is misbehaving in production, skip to the "Explicit Keys" section. You can come back for the theory later. I won't judge.

Laravel's Cache Facade: Quick Refresher

You probably know this already, but let's make sure we're on the same page:

// Basic stuff
Cache::put('user_123_profile', $userData, now()->addMinutes(30));
$profile = Cache::get('user_123_profile');

// The pattern you'll use everywhere
$profile = Cache::remember('user_123_profile', 3600, function () {
    return User::with('profile')->find(123);
});

Simple. Clean. Works great until you need to invalidate a bunch of related stuff at once.

That's when most tutorials tell you: "Just use cache tags!"

Yeah, about that...

Cache Tags: What They Don't Tell You in the Docs

Cache tags in Laravel let you group related cache items together so you can invalidate them as a group. It's useful when you have interconnected cached data that needs to be cleared together.

Cache tags look amazing in examples:

Cache::tags(['users', 'user_123'])->put('profile_data', $data, 3600);

// Later, flush everything for this user
Cache::tags(['user_123'])->flush();

Clean, right? Here's what's actually happening in your Redis instance.

The Ugly Truth: How Tags Actually Work

When you write that innocent line of code, Laravel does this behind the scenes:

Step 1: Creates a random "version" for each tag

tag:users:key -> "abc123"
tag:user_123:key -> "def456"

Step 2: Your actual key becomes a Frankenstein monster

abc123|def456|profile_data -> {your actual data}

Step 3: Tracks membership in Redis Sets

tag:users:entries -> SET["abc123|def456|profile_data", ...]
tag:user_123:entries -> SET["abc123|def456|profile_data", ...]

Three extra Redis operations. For every. Single. Cache write.

The Real Kicker: What flush() Does

Here's the part that got me. When you call Cache::tags(['user_123'])->flush():

1. Laravel generates a NEW random version for the tag

2. Updates the version key

3. Deletes the entries set

Notice what's missing? It doesn't delete your actual cached data.

Your data is now orphaned. It sits there, taking up memory, until the TTL expires. The next lookup generates a different composite key and misses the old data.

// Before flush: looks for "abc123|def456|profile_data"
// After flush: looks for "abc123|xyz789|profile_data" (cache miss!)
// Meanwhile: "abc123|def456|profile_data" is still chilling in Redis

In a busy system with frequent flushes? You end up with tons of zombie data.

🚨 War Story

We were flushing tags on every new message. With 1000 messages per day and 30-day TTLs on some keys, we had accumulated gigabytes of orphaned cache entries. Redis was sweating harder than me during that incident call.

The Four Horsemen of Cache Tag Problems

1. Memory Bloat (The Silent Killer)

Monday morning:  1,000 cache entries
                 Tag flushed 10 times throughout the day
                 Result: Up to 10,000 orphaned entries

Friday evening:  You're wondering why Redis is using 4GB

2. The Entries Set Grows Forever

Every tagged cache entry adds to tag:users:entries. In a busy app:

tag:users:entries -> SET with 100,000+ members

When you flush? Laravel deletes this entire set. That's O(N). Your Redis blocks.

3. Race Conditions That'll Make You Question Reality

T1: Request A starts, gets tag version "abc123"
T2: Request B flushes, tag version becomes "xyz789"
T3: Request A writes cache with old version "abc123"
T4: Request A's data is immediately orphaned

This one took me hours to debug. The cache was "working" but data kept disappearing randomly.

4. Debugging Is Basically Impossible

Try finding a specific cached item in production:

redis-cli KEYS "*profile*"
# Returns: "abc123|def456|profile_data"
# Cool, but... which user? Which tag version? Is this orphaned?

Compare that to explicit keys:

redis-cli KEYS "*user:123*"
# Returns: "myapp:user:123:profile"
# Ah, user 123's profile. Got it.

💡 Pro Tip

If you're already using tags and can't migrate immediately, at least set shorter TTLs. 5 minutes of orphaned data is way better than 24 hours.

Explicit Keys: The "Boring" Solution That Actually Works

I know, I know. Manually managing cache keys sounds tedious. But hear me out.

A Simple Key Builder

class CacheKey
{
    private const PREFIX = 'myapp';

    public static function userProfile(int $userId): string
    {
        return self::PREFIX . ":user:{$userId}:profile";
    }

    public static function conversation(string $id): string
    {
        return self::PREFIX . ":conv:{$id}:data";
    }

    public static function userConversationState(int $userId, string $convId): string
    {
        return self::PREFIX . ":user:{$userId}:conv:{$convId}:state";
    }
}

Boring? Maybe. But now:

• Every key is predictable, given the inputs, you know exactly what the key is

• No mystery composite keys

• No orphaned data

• redis-cli actually works for debugging

The "But I Have To Know What To Invalidate" Objection

Yes, you do. And honestly? That's a feature, not a bug.

With tags, you're thinking: "I'll just flush the tag and magic happens!"

With explicit keys, you're forced to think: "What exactly needs to be invalidated when X happens?"

That second mindset leads to better cache design. Trust me on this one.

Let's Talk Redis Operations (The Fun Part)

Alright, now that we've established explicit keys are the way to go, let's talk about how to actually use Redis efficiently. Because there's more to life than Cache::get() and Cache::put().

🎯 Quick Reference

• Strings: Simple values, full read/write

• Hashes: Structured data, partial updates

• INCR/DECR: Counters without race conditions

• Pipeline: Batch operations, one network trip

• UNLINK: Delete without blocking

Hashes: For When You Don't Want to Serialize Everything

Laravel's Cache::put() serializes your entire object. Every time. Even if you just want to update one field.

Redis Hashes let you store structured data and update individual fields:

// Store user state as a hash
Redis::hset('user:123:state', 'online', '1');
Redis::hset('user:123:state', 'last_seen', now()->timestamp);
Redis::hset('user:123:state', 'theme', 'dark');

// Update just one field (no serialization overhead)
Redis::hset('user:123:state', 'last_seen', now()->timestamp);

// Get everything
$state = Redis::hgetall('user:123:state');
// ['online' => '1', 'last_seen' => '1699123456', 'theme' => 'dark']

// Or just one field
$theme = Redis::hget('user:123:state', 'theme');

Under the hood, Redis stores small hashes in a "ziplist", a super compact format. One hash with 10 fields uses less memory than 10 separate keys.

When I use this: User preferences, session data, feature flags, any structured data with frequent partial updates.

INCR/DECR: Counters That Don't Lie

Here's a bug I've seen in codebases more times than I'd like to admit:

// The wrong way (race condition waiting to happen)
$count = Cache::get('page_views');
Cache::put('page_views', $count + 1);

Two requests hit this simultaneously, both read 100, both write 101. You just lost a page view.

Redis's atomic counters fix this:

Redis::incr('page_views');  // Always correct, even with 1000 concurrent requests
Redis::incrby('user:123:points', 50);
Redis::decr('inventory:item_456');

These are atomic because Redis is single-threaded for command execution. The increment happens in one uninterruptible operation.

Example on how to properly cache the unread count:

public function onNewMessage(string $recipientId): void
{
    $key = "user:{$recipientId}:unread";
    Redis::incr($key);
    Redis::expire($key, 3600);  // Reset TTL
}

public function onMessageRead(string $userId): void
{
    $key = "user:{$userId}:unread";
    if ((int) Redis::get($key) > 0) {
        Redis::decr($key);
    }
}

No locks. No race conditions. Just works.

⚡ Performance Note

Atomic operations are not just correct, they're fast. One INCR command vs. GET + calculation + SET. That's 3x fewer network round trips.

Pipeline: Because Network Latency Adds Up

Every Redis command is a network round trip. If your latency is 1ms (which is pretty good), 100 commands = 100ms of just waiting.

// Slow: 50 round trips
foreach ($userIds as $userId) {
    Redis::del("user:{$userId}:conv:{$convId}:state");
}

// Fast: 1 round trip
Redis::pipeline(function ($pipe) use ($userIds, $convId) {
    foreach ($userIds as $userId) {
        $pipe->del("user:{$userId}:conv:{$convId}:state");
    }
});

With pipelining, all commands get sent together, Redis processes them in order, and all responses come back together.

Heads up though: Pipelines aren't atomic. Other clients' commands can interleave between yours. If you need atomicity, look into Redis transactions or Lua scripts.

DEL vs UNLINK: The Optimization That Saved Our Bacon

This one's subtle but important.

DEL is synchronous. When you delete a key, Redis:

1. Removes it from the hash table

2. Frees the memory

3. Then moves on to the next command

For big values (large strings, hashes with thousands of fields), that memory deallocation takes time. And during that time, Redis can't do anything else. Your fast reads are stuck waiting behind a slow delete.

UNLINK (Redis 4.0+) is the async version:

1. Removes the key from the hash table immediately

2. Queues the memory for background cleanup

3. Moves on to the next command instantly

// Might block if the value is large
Redis::del('big_cached_object');

// Returns immediately, always
Redis::unlink('big_cached_object');

The difference in practice:

When we switched our bulk invalidation from DEL to UNLINK in pipelines, our P99 latency dropped significantly. It's one of those changes that costs nothing and helps a lot.

🔥 Hot Take

Just use UNLINK everywhere. I can't think of a single case where you actually need the synchronous memory-freeing behavior of DEL. If you know of one, I'd genuinely love to hear it.

EXPIRE: How Redis Actually Handles TTL

Quick detour into Redis internals because this tripped me up once.

Redis doesn't have a background process constantly checking "is this key expired yet?" That would be expensive.

Instead, it uses two strategies:

Passive expiration: When you try to access a key, Redis checks if it's expired. If yes, it deletes it right there and returns null.

Active expiration: 10 times per second, Redis samples 20 random keys that have a TTL. If more than 25% are expired, it samples again immediately.

The cleanup loop:
1. Pick 20 random keys with TTL
2. Delete the expired ones
3. If >25% were expired, go to step 1
4. Otherwise, wait 100ms and start over

Why this matters: Keys might live slightly past their expiration until they're accessed or randomly sampled. Don't rely on TTL for precise timing, use a proper scheduler for that.

💡 Keep In Mind

Use Cache::rememberForever carefully. Having too many rememberForever keys can fill up Redis memory. Instead of just considering how rarely the data changes, think about how often it is accessed. Using rememberForever on data that rarely accessed over time isn't a good idea.

Putting It Together: What Our Cache Service Looks Like Now

Here's a simplified version of what we ended up with:

class ConversationCache
{
    private const CONV_TTL = 1800;      // 30 min (data rarely changes)
    private const STATE_TTL = 900;       // 15 min (changes often)
    private const UNREAD_TTL = 3600;     // 1 hour (expensive to compute)

    public function getConversation(string $id): ?array
    {
        $key = "conv:{$id}:data";

        try {
            $cached = Cache::get($key);
            if ($cached !== null) {
                return $cached;
            }

            $data = $this->loadFromDatabase($id);
            if ($data) {
                Cache::put($key, $data, self::CONV_TTL);
            }
            return $data;

        } catch (RedisException $e) {
            // Redis down? Just hit the database.
            Log::warning('Redis unavailable', ['error' => $e->getMessage()]);
            return $this->loadFromDatabase($id);
        }
    }

    public function getUserState(string $userId, string $convId): array
    {
        $key = "user:{$userId}:conv:{$convId}:state";

        $state = Redis::hgetall($key);

        if (empty($state)) {
            $state = $this->loadStateFromDb($userId, $convId);
            Redis::hset($key, 'read', $state['read'] ? '1' : '0');
            Redis::hset($key, 'archived', $state['archived'] ? '1' : '0');
            Redis::expire($key, self::STATE_TTL);
        }

        return [
            'read' => ($state['read'] ?? '0') === '1',
            'archived' => ($state['archived'] ?? '0') === '1',
        ];
    }

    public function invalidateForParticipants(string $convId, array $userIds): void
    {
        if (empty($userIds)) return;

        Redis::pipeline(function ($pipe) use ($userIds, $convId) {
            foreach ($userIds as $userId) {
                $pipe->unlink("user:{$userId}:conv:{$convId}:state");
            }
        });
    }
}

Notice the patterns:

• Explicit, predictable keys

• Redis Hashes for structured state

• Pipeline + UNLINK for bulk invalidation

• Graceful degradation, if Redis dies, we fall back to the database

📊 The Numbers

Before and after the refactor:

Metric	Cache Tags	Explicit Keys
Queries per page	300+	3-5
Orphaned cache data	Large	Zero
Redis memory growth	Unbounded	Stable
Time to debug cache issues	Hours	Minutes
My stress levels	High	Manageable

Wrapping Up

Look, cache tags aren't evil. For a small app with low traffic, they're fine. Convenient, even.

But if you're building something that needs to scale, or you're debugging mysterious cache inconsistencies at 2am, explicit keys are worth the extra thought upfront.

The cache design that saved me:

1. Deterministic keys via a builder class

2. Layered TTLs based on how often data changes

3. Redis Hashes for structured data with partial updates

4. Atomic counters for anything that increments

5. Pipeline + UNLINK for bulk operations

6. Graceful fallbacks when Redis misbehaves

It's not glamorous. It won't get you Twitter famous. But it works, it scales, and it's debuggable. In production, that's what matters.

Got questions? Found a mistake? Built something cool with these patterns? Hit me up, always happy to chat about making things faster and optimized.

See you again with another war story. Till then, then.

What Even Is Route Model Binding?

Before we dive deep, let's get on the same page. Route model binding is a pattern (popularized by Laravel, but available in many frameworks) where instead of manually fetching a model from the database using an ID from the route, the framework does it automatically for you.

Instead of this:

public function update(Request $request, $userId)
{
    $user = User::findOrFail($userId);
    // your logic
}

You write this:

public function update(Request $request, User $user)
{
    // $user is already loaded and ready
}

Simple, clean, elegant. But the question is:

Is it smart?

The "Database Query Before Validation" Argument

Let's address the elephant in the room first.

Yes, route model binding executes a database query before your validation logic runs. And yes, if someone sends a malformed request with an invalid user ID, you'll hit the database unnecessarily.

But here's the thing,

This concern is largely theoretical in real-world applications.

Think about it. What percentage of your API requests are genuinely malformed? If your answer is "a lot," you have bigger problems than route model binding, you have a security issue. In a properly secured API with authentication, rate limiting, and basic input sanitization at the gateway level, malicious or malformed requests should be a tiny fraction of your traffic.

For the 99.9% of legitimate requests? That "premature" database query is happening anyway. You're just deciding when and how it happens.

Why Route Model Binding Matters

1. Consistency Is King

In large enterprise applications, you might have hundreds of API endpoints across dozens of controllers. Without route model binding, each developer on your team decides how to fetch and handle models.

You end up with,

• findOrFail() in some places

• find() with manual null checks in others

• Custom error messages everywhere

• Different HTTP status codes for the same scenario

Route model binding enforces a consistent pattern. Every resource that doesn't exist returns a 404. Every fetched model is guaranteed to be non-null. No surprises.

2. Authorization Gets Easier

Here's where it gets really good. With route model binding, you can leverage authorization policies cleanly.

public function update(Request $request, User $user)
{
    $this->authorize('update', $user);

    // If we reach here, user exists AND current user can update it
}

Without it, you're doing this dance.

public function update(Request $request, $userId)
{
    $user = User::find($userId);

    if (!$user) {
        return response()->json(['error' => 'Not found'], 404);
    }

    if (!$request->user()->can('update', $user)) {
        return response()->json(['error' => 'Forbidden'], 403);
    }

    // Finally, your actual logic
}

Which approach scales better across 200 endpoints?

3. Type Safety and IDE Support

This might seem minor, but in large codebases, it's huge. With route model binding, your IDE knows exactly what type $user is. You get autocomplete, type hints, and static analysis tools can catch errors at compile time rather than runtime.

public function show(User $user)
{
    return $user->profile->bio; // IDE knows this is a User
}

Compare that to:

public function show($id)
{
    $user = User::find($id); // Could be User|null
    return $user->profile->bio; // Static analyzers scream
}

4. Scoped Bindings for Complex Relationships

This is where route model binding truly shines in enterprise apps. Imagine you have a multi-tenant application where posts belong to workspaces:

Route::get('/workspaces/{workspace}/posts/{post}', [PostController::class, 'show']);

With scoped binding:

public function show(Workspace $workspace, Post $post)
{
    // $post is automatically scoped to $workspace
    // If post doesn't belong to workspace, automatic 404
}

Without it? You're writing this logic manually in every single controller method. And someone will forget. And you'll have a security vulnerability.

The Performance "Problem" That Isn't

Let's talk numbers because this is where the "database query before validation" argument falls apart.

Scenario 1: Malformed Request (Invalid ID)

• With binding: 1 failed DB query (~5ms)

• Without binding: Validation passes, then failed DB query (~5ms)

• Difference: 0ms (you query either way, just in different order)

Scenario 2: Valid Request, Valid ID

• With binding: 1 DB query (~5ms)

• Without binding: 1 DB query (~5ms)

• Difference: 0ms

Scenario 3: Valid Request, Validation Fails

• With binding: 1 DB query (~5ms) + validation

• Without binding: Validation + 0 DB queries

• Difference: ~5ms saved

So we're talking about saving 5 milliseconds on requests that fail validation. In a properly built API with good client-side validation and authenticated users, this is maybe 0.1% of your traffic.

Meanwhile, you're gaining:

• Cleaner code (priceless)

• Fewer bugs (saves hours of debugging)

• Consistent error handling (better user experience)

• Easier authorization (better security)

Enterprise-Scale Advantages

Middleware Integration

Route model binding works beautifully with middleware. You can create middleware that operates on bound models:

Route::middleware(['auth', 'can:update,post'])
    ->put('/posts/{post}', [PostController::class, 'update']);

The model is available to middleware, allowing you to build powerful, reusable authorization logic.

Eager Loading and N+1 Prevention

You can customize your bindings to eager load relationships:

public function resolveRouteBinding($value, $field = null)
{
    return $this->with(['author', 'comments', 'tags'])->findOrFail($value);
}

Now every endpoint using that model automatically gets optimized queries. Try coordinating that across 50 developers without route binding.

API Versioning

When you need to version your API, route model binding makes it trivial.

// v1 - simple binding
Route::get('/v1/users/{user}', [V1\UserController::class, 'show']);

// v2 - different binding strategy
Route::get('/v2/users/{user}', [V2\UserController::class, 'show']);

Each version can customize how models are resolved without touching core logic.

When You Might Actually Want to Skip It

Look, I'm not saying route model binding is perfect for every scenario. There are legitimate cases to skip it:

1. Bulk operations with hundreds of IDs: If you're processing POST /batch-update with 500 IDs, don't bind 500 models. Use a custom approach.

2. Soft deletes with different behavior: If different endpoints need different soft delete handling, manual fetching might be clearer.

3. Complex custom queries: If you need to join 5 tables and filter by 10 conditions, a custom repository method makes more sense.

But these are edge cases. For your standard CRUD REST API endpoints? Route model binding is the way to go.

The Real Cost of "Optimizing" Too Early

Here's what I've seen in enterprise codebases that avoided route model binding for "performance".

• 47 different ways to fetch and validate a User model

• Inconsistent error responses confusing mobile developers

• Authorization bugs because someone forgot to check ownership

• Hours wasted in code reviews debating the "right" way to fetch models

• N+1 queries everywhere because each developer handles eager loading differently

All to save 5 milliseconds on a fraction of requests that fail validation.

That's not optimization. That's premature optimization. And as Donald Knuth said, it's the root of all evil.

The Bottom Line

Route model binding is a pattern that favors maintainability, consistency, and developer experience over a theoretical performance concern that rarely matters in practice.

In large enterprise REST APIs where you have,

• Multiple developers

• Hundreds of endpoints

• Complex authorization requirements

• Need for consistency

• Long-term maintenance

Route model binding isn't just a “nice to have”. It's a force multiplier that keeps your codebase clean and your team productive.

Should you use it everywhere blindly? No. Should you avoid it because of a database query that happens 5ms earlier than you'd like? Absolutely not.

Next time someone tells you route model binding is bad, ask them: what's the alternative? Manual model fetching in every single controller method? Because I've maintained both codebases, and I know which one I'd rather work in.

Until next time!

But (oh yes! There is a BUT) here's the thing, I've been watching Laravel developers (including myself) fall into what I call the "AI Eloquent Trap," and it's like watching someone become a master chef by only using meal kits. Sure, the food tastes great and looks professional, but ask them to cook without the pre-portioned ingredients and suddenly they're staring at raw chicken wondering why it doesn't come with built-in cooking instructions. 🍗

Today I'm going to share some hard truths about what happens when Laravel developers become too dependent on AI for their development work. And before you close this tab thinking "Here comes another old-school developer ranting about the good old days", let me be clear! I LOVE AI tools for Laravel development. They're game-changers. But like using dd() everywhere instead of proper debugging, AI can become a crutch that prevents you from truly understanding the beautiful framework you're working with.

The Honeymoon Phase: When AI Makes Laravel Feel Like Magic ✨

Remember your first week using AI for Laravel development? It was like having Taylor Otwell himself pair programming with you:

// You: "Create a User model with profile relationship"
// AI: *Instantly generates perfect Eloquent model*

<?php

namespace App\Models;

use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Relations\HasOne;

class User extends Authenticatable
{
    use HasFactory;

    protected $fillable = ['name', 'email', 'password'];

    protected $hidden = ['password', 'remember_token'];

    protected $casts = [
        'email_verified_at' => 'datetime',
        'password' => 'hashed',
    ];

    public function profile(): HasOne
    {
        return $this->hasOne(Profile::class);
    }
}

// You: "Holy crap, it even knows about the new password hashing!"

// You: "Build me a complete blog API with authentication"
// AI: *Generates 15 files with routes, controllers, requests, resources*

// routes/api.php
Route::middleware('auth:sanctum')->group(function () {
    Route::apiResource('posts', PostController::class);
    Route::post('posts/{post}/comments', [CommentController::class, 'store']);
});

// app/Http/Controllers/PostController.php
class PostController extends Controller
{
    public function index(Request $request): JsonResponse
    {
        $posts = Post::with(['user', 'comments'])
            ->when($request->search, fn($q) => $q->where('title', 'like', "%{$request->search}%"))
            ->latest()
            ->paginate();

        return response()->json(new PostCollection($posts));
    }

    // ... perfect CRUD implementation
}

// You: "I'm never writing boilerplate again!"

It felt like having superpowers. Like Jarvis to Tony Stark. Suddenly, you were shipping Laravel features at warp speed, your code reviews were getting approved instantly, and you felt like you'd unlocked the secret to being a 10x Laravel developer.

The Dependency Trap: When Your Laravel Superpowers Become Your Kryptonite 🕸️

But then something subtle started happening. Let me paint you a picture of what Laravel AI over-dependence looks like in the wild.

⛔️ The "I Can't Remember Artisan Commands" Syndrome

This actually happened to a Laravel developer I knew. Their AI assistant license expired.

Task: Create a new controller.

What they used to type instinctively,

php artisan make:controller UserController --resource

What they actually did:

1. Stared at terminal for 5 minutes

2. Tried: php artisan create:controller UserController

3. Tried: php artisan generate:controller UserController

4. Finally googled "laravel create controller command"

5. Spent 20 minutes reading documentation they used to know by heart

Even worse - they couldn't remember,

php artisan make:model Post -mfsc #command to create migration, factory, seeder, controller at once

And had to create each file individually like a caveman.

⛔️ The "Copy-Paste Eloquent Without Understanding" Disaster

// AI generated this beautiful relationship setup:
class User extends Model
{
    public function posts(): HasMany
    {
        return $this->hasMany(Post::class);
    }

    public function publishedPosts(): HasMany
    {
        return $this->hasMany(Post::class)->where('status', 'published');
    }

    public function recentPosts(): HasMany
    {
        return $this->hasMany(Post::class)
            ->where('created_at', '>=', now()->subDays(30))
            ->latest();
    }

    public function popularPosts(): HasMany
    {
        return $this->hasMany(Post::class)
            ->withCount('likes')
            ->having('likes_count', '>', 100)
            ->orderBy('likes_count', 'desc');
    }
}

Developer copies it, uses it for months.

Then one day performance tanks and they have NO IDEA why.

"Why is this query so slow? What's N+1? Why are there so many database calls?

What does 'withCount' do? Should I use 'with' or 'load'?"

The AI code looked clean, but it was generating queries like:

SELECT * FROM posts WHERE user_id = 1 AND status = 'published'
SELECT * FROM posts WHERE user_id = 1 AND created_at >= '2024-01-01'  
SELECT * FROM posts WHERE user_id = 1 ORDER BY created_at DESC
// ... for EVERY user in a loop = database meltdown

⛔️ The "AI Said It Follows Laravel Conventions" Bug Hunt

// AI confidently provided this "Laravel-style" authentication:
class AuthController extends Controller
{
    public function login(LoginRequest $request)
    {
        $credentials = $request->validated();

        if (Auth::attempt($credentials)) {
            $user = Auth::user();
            $token = $user->createToken('auth-token')->plainTextToken;

            return response()->json([
                'token' => $token,
                'user' => $user,
            ]);
        }

        return response()->json(['message' => 'Invalid credentials'], 401);
    }

    public function logout(Request $request)
    {
        $request->user()->currentAccessToken()->delete();
        return response()->json(['message' => 'Logged out']);
    }
}

Looks perfect, right? AI knows Laravel best practices!

Until production, when:

1. No rate limiting (welcome brute force attacks!)

2. No proper API resource transformation (exposing all user data)

3. No token expiration handling

4. No refresh token mechanism

5. Missing CSRF protection setup

6. No audit trail for login attempts

7. Token revocation doesn't clear all user sessions

The Laravel Skills You're Secretly Losing 🧠💸

Here's what happens when you let AI do all the heavy Laravel lifting.

Eloquent Query Optimization Amnesia

Old you (pre-AI)

Problem: Get users with their post count and latest comment

Process:

1. Think about the relationships

2. Consider eager loading vs lazy loading

3. Plan the most efficient query

4. Test with Laravel Debugbar

public function getUsersWithData()
{
    return User::withCount('posts')
        ->with(['posts' => function($query) {
            $query->latest()->limit(1)->with('latestComment');
        }])
        ->get();
}

New you (AI-dependent)

Problem: Get users with their post count and latest comment

Process:

1. Ask AI

2. Copy-paste result

3. Hope it doesn't kill the database

$users = User::all();
foreach($users as $user) {
    $user->posts_count = $user->posts()->count();
    $user->latest_post = $user->posts()->latest()->first();
    if($user->latest_post) {
        $user->latest_comment = $user->latest_post->comments()->latest()->first();
    }
}

You: "Cool, it works! ...but why is my app suddenly slow? What's this N+1 thing in the logs? How do I fix this?"

Service Container and Dependency Injection Confusion

Error: "Target class [PaymentService] does not exist"

Old you:

1. Check if the service is bound in a service provider

2. Verify the namespace and autoloading

3. Understand constructor injection vs manual resolution

4. Know when to use interfaces vs concrete classes

// app/Providers/AppServiceProvider.php
public function register()
{
    $this->app->bind(PaymentServiceInterface::class, StripePaymentService::class);
}

New you:

1. Copy error to AI

2. Paste suggested fix without understanding Laravel's service container

3. When it breaks differently, repeat step 1

// AI suggests adding to controller:
public function __construct()
{
    $this->paymentService = app(PaymentService::class);
}

You add it, it works, but you never learned:

1. How Laravel's service container works

2. Why dependency injection is better than service location

3. How to properly bind interfaces

4. When to use singletons vs regular bindings

5. How service providers organize your application

Laravel Architecture Patterns Evaporating

// AI builds you this "feature":
class OrderController extends Controller 
{
    public function store(Request $request)
    {
        // Validation directly in controller
        $request->validate([
            'items' => 'required|array',
            'items.*.product_id' => 'required|exists:products,id',
            'items.*.quantity' => 'required|integer|min:1',
        ]);

        // Business logic mixed with HTTP concerns
        DB::transaction(function() use ($request) {
            $order = Order::create([
                'user_id' => auth()->id(),
                'total' => 0,
            ]);

            $total = 0;
            foreach($request->items as $item) {
                $product = Product::find($item['product_id']);

                // Stock checking inline
                if($product->stock < $item['quantity']) {
                    throw new Exception('Insufficient stock');
                }

                // Price calculation inline  
                $lineTotal = $product->price * $item['quantity'];
                if($product->discount > 0) {
                    $lineTotal *= (1 - $product->discount / 100);
                }

                // Inventory updates inline
                $product->decrement('stock', $item['quantity']);

                // Order item creation inline
                $order->items()->create([
                    'product_id' => $item['product_id'],
                    'quantity' => $item['quantity'],
                    'unit_price' => $product->price,
                    'total_price' => $lineTotal,
                ]);

                $total += $lineTotal;
            }

            $order->update(['total' => $total]);

            // Email sending in controller
            Mail::to($order->user)->send(new OrderConfirmationMail($order));

            // External API calls in controller
            Http::post('https://shipping-api.com/create-shipment', [
                'order_id' => $order->id,
                'items' => $order->items,
            ]);

            return response()->json(['order' => $order]);
        });
    }
}

You: "Wow, AI built me a complete order system!"

Reality: This violates every Laravel best practice and will be unmaintainable

But you don't recognize the problems:

1. Fat controller with business logic

2. No form request validation

3. No service layer separation

4. No event handling for order creation

5. No job queuing for external API calls

6. No proper error handling

7. No inventory service abstraction

8. No pricing service abstraction

The "AI Knows Laravel Better Than Me" Mentality Crisis 🎭

The Performance Problem You Can't See

// AI cheerfully generates this "optimized" blog listing:
class PostController extends Controller
{
    public function index(Request $request)
    {
        $posts = Post::with(['user', 'comments.user', 'tags', 'categories'])
            ->when($request->search, function($query) use ($request) {
                return $query->where('title', 'like', "%{$request->search}%")
                           ->orWhere('content', 'like', "%{$request->search}%");
            })
            ->when($request->category, function($query) use ($request) {
                return $query->whereHas('categories', function($q) use ($request) {
                    $q->where('slug', $request->category);
                });
            })
            ->when($request->tag, function($query) use ($request) {
                return $query->whereHas('tags', function($q) use ($request) {
                    $q->where('slug', $request->tag);
                });
            })
            ->withCount(['comments', 'likes'])
            ->latest()
            ->paginate(10);

        return view('posts.index', compact('posts'));
    }
}

Looks clean and Laravel-like, right?

But this generates massive queries like,

SELECT posts.*, 
    (SELECT COUNT(*) FROM comments WHERE post_id = posts.id) as comments_count,
    (SELECT COUNT(*) FROM likes WHERE post_id = posts.id) as likes_count
FROM posts 
WHERE (title LIKE '%laravel%' OR content LIKE '%laravel%')
ORDER BY created_at DESC

Plus separate queries for,

1. All users for loaded posts

2. All comments for each post

3. All users for each comment

4. All tags for each post

5. All categories for each post

For 10 posts with 5 comments each = 50+ database queries Your app crawls, but you don't know why because AI made it "look proper"

The Laravel Convention Blind Spot

// AI generates this "RESTful" Laravel controller:
class UserManagementController extends Controller
{
    public function getAllUsers() // Should be index()
    {
        return User::all(); // No pagination, no resource transformation
    }

    public function getUserById($id) // Should be show(User $user)
    {
        return User::find($id); // No model binding, no 404 handling
    }

    public function createUser(Request $request) // Should be store()
    {
        return User::create($request->all()); // No validation, mass assignment vulnerability
    }

    public function updateUser($id, Request $request) // Should be update(User $user)
    {
        $user = User::find($id);
        $user->update($request->all()); // No validation, no authorization
        return $user;
    }

    public function deleteUser($id) // Should be destroy(User $user)
    {
        User::find($id)->delete(); // No soft deletes consideration
        return ['message' => 'deleted'];
    }
}

Looks functional, right? Wrong!

1. Ignores Laravel naming conventions

2. No route model binding

3. No proper HTTP status codes

4. No API resource transformation

5. No authorization policies

6. No form request validation

7. Mass assignment vulnerabilities everywhere

You deploy this thinking "AI knows REST best practices!"

Laravel developers everywhere: collective facepalm 🤦‍♂️

When AI Becomes Your Laravel Team's Kryptonite 💀

The Laravel Knowledge Sharing Breakdown

Before AI

Junior dev: "How do Laravel service providers work?"

Senior dev: Explains container binding, boot vs register, when to use each

Junior dev: Learns fundamental Laravel concepts, understands the framework

After AI overdependence

Junior dev: "How do Laravel service providers work?"

Senior dev: "I asked AI to create them. Just use what it generated."

Junior dev: "But what if we need to modify the binding logic?"

Senior dev: "Ask AI to modify it."

Junior dev: "What if we need different providers for different environments?"

Senior dev: "...Ask AI about environment-specific providers?"

Result: Team of Laravel copy-paste programmers with no framework understanding

The Laravel Code Review Nightmare

Pull request title: "Add e-commerce functionality"

Changes: 847 lines of AI-generated Laravel code

Comments from reviewer

Reviewer: "Why are we not using Laravel's built-in validation?"

Developer: "AI used custom validation. It works fine."

Reviewer: "This breaks single responsibility. Why is payment logic in the controller?"

Developer: "AI organized it this way. Seems logical."

Reviewer: "Where are the tests for this feature?"

Developer: "Good point. AI, write tests for this e-commerce functionality."

Reviewer: "Why aren't we using Eloquent relationships here?"

Developer: "AI used manual joins. Performance reasons, probably."

Reviewer: starts updating LinkedIn profile 🤦🏻‍♂️

The Right Way to Use AI with Laravel: Your Framework Assistant, Not Replacement 👨‍🍳

AI as a Laravel Learning Accelerator

Instead of

"AI, build me a complete authentication system"

Try

"Explain Laravel Sanctum vs Passport vs custom JWT implementation"

AI explains the differences and use cases

Then: "Show me a basic Sanctum implementation with explanation"

AI provides code with detailed comments

Then: "What security considerations should I add to this?"

AI explains rate limiting, token rotation, CSRF protection

Finally: You implement and adapt based on your understanding

AI for Laravel Code Review and Optimization

// Use AI to review YOUR Laravel code:
class PostController extends Controller 
{
    public function index()
    {
        $posts = Post::all();
        foreach($posts as $post) {
            $post->author = User::find($post->user_id);
            $post->comment_count = Comment::where('post_id', $post->id)->count();
        }
        return view('posts.index', compact('posts'));
    }
}

Prompt: "Review this Laravel controller for N+1 queries and suggest Eloquent improvements"

AI suggests: eager loading, withCount, proper relationships

You learn: Laravel query optimization, Eloquent best practices

AI for Explaining Complex Laravel Patterns

// When you encounter complex Laravel architecture:
class OrderService
{
    public function __construct(
        private InventoryService $inventory,
        private PaymentService $payment,
        private ShippingService $shipping,
        private EventDispatcher $events
    ) {}

    public function processOrder(OrderData $orderData): Order
    {
        return DB::transaction(function() use ($orderData) {
            $this->inventory->reserve($orderData->items);
            $order = Order::create($orderData->toArray());
            $payment = $this->payment->charge($orderData->paymentMethod, $order->total);
            $shipment = $this->shipping->createShipment($order);
            $this->events->dispatch(new OrderProcessed($order, $payment, $shipment));
            return $order;
        });
    }
}

Instead of blindly copying, ask AI,

"Explain this Laravel service pattern and dependency injection"

"What Laravel features are being used here and why?"

"How would I test this service with Laravel's testing tools?"

"What events should I listen for in this order processing flow?"

Now you understand Laravel patterns before you implement them.

The Balanced Laravel Approach: Building AI-Enhanced Skills 🎯

The 70-20-10 Rule for Laravel Development

• 70% Laravel Fundamentals: Eloquent, routing, middleware, service container, testing

• 20% AI-Assisted Laravel: Using AI to accelerate known Laravel patterns

• 10% AI Laravel Exploration: Experimenting with cutting-edge AI capabilities for Laravel

The "Explain It Back" Laravel Test

After using AI to generate Laravel code, can you:

1. Explain the Laravel concepts being used?

2. Modify it following Laravel conventions?

3. Write Laravel tests for it?

4. Debug it using Laravel's debugging tools?

5. Optimize it using Laravel's performance features?

If you answered "no" to any of these, you're probably too dependent on AI.

The Laravel Recovery Program: Getting Your Framework Skills Back 💪

Step 1: Pure Laravel Cold Turkey

Build a simple Laravel app entirely without AI assistance.

Build a task management app

1. User authentication (Laravel Breeze/Sanctum)

2. CRUD operations with proper form requests

3. Eloquent relationships between Users and Tasks

4. Authorization using policies

5. Feature tests for all functionality

You'll rediscover

1. How Laravel's directory structure works

2. What Artisan commands actually do

3. How service providers organize your app

4. Why Laravel's conventions matter

5. How Eloquent relationships really work

Step 2: Manual Laravel Debugging

When your Laravel app breaks, resist AI and use Laravel's tools

Instead of pasting errors to AI,

1. Use Laravel's error pages and stack traces

2. Check Laravel logs with tail -f storage/logs/laravel.log

3. Use Laravel Debugbar for query analysis

4. Debug with dd(), dump(), and Xdebug

5. Read Laravel documentation for the feature you're using

Step 3: Laravel Architecture from Scratch

Plan a blog system without using AI

1. Design database schema following Laravel conventions

2. Plan Eloquent models and relationships

3. Design RESTful routes following Laravel naming

4. Structure controllers using Laravel best practices

5. Plan service layer and repository patterns

6. Design authorization using Laravel policies

7. Plan testing strategy with Laravel's test tools

Example planning

Models: User, Post, Comment, Tag, Category

Relationships: User hasMany Posts, Post hasMany Comments, etc.

Controllers: PostController, CommentController (resource controllers)

Middleware: auth, throttle, custom admin middleware

Policies: PostPolicy for authorization

Tests: Feature tests for API, Unit tests for services

Step 4: Laravel Code Review and Refactoring

Take AI-generated Laravel code and make it truly Laravel-like

// AI-generated code often looks like this:
class BlogController extends Controller
{
    public function getPosts(Request $request)
    {
        $query = "SELECT * FROM posts WHERE status = 'published'";
        if($request->get('search')) {
            $query .= " AND title LIKE '%" . $request->get('search') . "%'";
        }
        $posts = DB::select($query);
        return response()->json($posts);
    }
}

// Refactor to proper Laravel:
class PostController extends Controller
{
    public function index(Request $request): JsonResponse
    {
        $posts = Post::published()
            ->when($request->search, fn($q) => $q->where('title', 'like', "%{$request->search}%"))
            ->with(['user', 'tags'])
            ->latest()
            ->paginate();

        return response()->json(new PostCollection($posts));
    }
}

Add proper,

1. Eloquent scopes (published())

2. Query builder methods

3. Eager loading

4. API resources

5. Proper naming conventions

The Bottom Line: AI as Your Laravel Copilot, Not Autopilot 🛠️

Look, AI is incredible for Laravel development. It can generate boilerplate, suggest Eloquent relationships, and even write decent tests. But here's the thing, Laravel developers who will thrive in the AI era aren't the ones who can prompt engineer the perfect controller. They're the ones who understand Laravel's philosophy so deeply that they can guide AI toward truly elegant, maintainable Laravel applications.

Think of AI like Laravel's make: commands on steroids. They're amazing for scaffolding and getting started quickly, but if you don't understand what the generated code does or how it fits into Laravel's ecosystem, you're building on a foundation of sand.

The Signs You're Using AI Right with Laravel:

• You can explain why AI chose specific Laravel patterns

• You modify AI suggestions to follow Laravel conventions better

• You catch when AI violates Laravel best practices

• You use AI to learn about new Laravel features

• You can build Laravel apps even when AI isn't available

The Signs You're Addicted to AI for Laravel:

• You panic when AI tools are down during Laravel development

• You can't remember basic Artisan commands

• You copy paste AI Laravel code without understanding the patterns

• You ask AI to debug Laravel-specific errors

• You've forgotten how to read Laravel documentation

Remember, AI should amplify your Laravel skills, not replace your understanding of the framework. The goal is to become an AI-enhanced Laravel developer, not an AI-dependent one who happens to work with PHP files.

The future belongs to Laravel developers who can dance with AI while staying true to Laravel's elegant conventions and patterns. Now go build something amazing in Laravel without asking AI for help. Taylor Otwell would be proud! 💪

P.S. - If reading this article made you realize you can't remember how to create a migration without AI assistance, don't panic. You're not broken, you're just out of practice. Start with php artisan make:migration and rediscover the joy of Laravel's beautiful conventions. The goal is not to never use AI, it's to use it to build better Laravel applications, not to avoid learning Laravel itself.

Today I am going to talk about something that will change the way you write Laravel applications forever, Test Driven Development (TDD). And before you roll your eyes and think "Oh great, another lecture about testing," hear me out. This isn't just about writing tests. This is about writing better code, sleeping better at night, and actually enjoying the development process.

What the Heck is TDD Anyway?

TDD isn't just writing tests after you've written your code (that's just regular testing, and honestly, most of us skip it anyway). TDD is a completely different mindset. You write the test FIRST, watch it fail, then write just enough code to make it pass. It's like having a conversation with your future self about what your code should actually do.

The cycle goes like this:

1. Red - Write a failing test

2. Green - Write the minimum code to make it pass

3. Refactor - Clean up your code while keeping tests green

Simple? Yes. Easy? Well, that's where things get interesting.

The Horror Story: Building Without TDD

Let me show you what building a Laravel feature typically looks like without TDD. We're going to build a simple user registration system with email verification.

The "Traditional" Approach (AKA The Nightmare)

// UserController.php
class UserController extends Controller
{
    public function register(Request $request)
    {
        // Validate the request
        $request->validate([
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users',
            'password' => 'required|string|min:8|confirmed',
        ]);

        // Create the user
        $user = User::create([
            'name' => $request->name,
            'email' => $request->email,
            'password' => Hash::make($request->password),
            'email_verification_token' => Str::random(60),
        ]);

        // Send verification email
        Mail::to($user->email)->send(new VerificationEmail($user));

        return response()->json(['message' => 'User registered successfully']);
    }

    public function verifyEmail($token)
    {
        $user = User::where('email_verification_token', $token)->first();

        if (!$user) {
            return response()->json(['error' => 'Invalid token'], 400);
        }

        $user->email_verified_at = now();
        $user->email_verification_token = null;
        $user->save();

        return response()->json(['message' => 'Email verified successfully']);
    }
}

Looks clean, right? Wrong! Here's what happens in real life:

1. You deploy this code

2. A user tries to register with an email that's already taken but with different casing

3. Your "unique" validation fails because MySQL is case-insensitive by default

4. User gets frustrated and leaves

5. You get angry Slack messages from your PM

6. You spend 2 hours debugging something that could have been caught with a simple test

The TDD Way: Building with Confidence

Now, let's see how we would approach this same feature using TDD. Buckle up, because this is where things get really interesting.

Step 1: Write the Test First

// tests/Feature/UserRegistrationTest.php
class UserRegistrationTest extends TestCase
{
    use RefreshDatabase;

    /** @test */
    public function user_can_register_with_valid_data()
    {
        Mail::fake();

        $response = $this->postJson('/api/register', [
            'name' => 'John Doe',
            'email' => 'john@example.com',
            'password' => 'password123',
            'password_confirmation' => 'password123',
        ]);

        $response->assertStatus(201)
                ->assertJson(['message' => 'User registered successfully']);

        $this->assertDatabaseHas('users', [
            'name' => 'John Doe',
            'email' => 'john@example.com',
        ]);

        $user = User::where('email', 'john@example.com')->first();
        $this->assertNotNull($user->email_verification_token);
        $this->assertNull($user->email_verified_at);

        Mail::assertSent(VerificationEmail::class, function ($mail) use ($user) {
            return $mail->hasTo($user->email);
        });
    }

    /** @test */
    public function registration_fails_with_duplicate_email_regardless_of_case()
    {
        User::factory()->create(['email' => 'john@example.com']);

        $response = $this->postJson('/api/register', [
            'name' => 'Jane Doe',
            'email' => 'JOHN@EXAMPLE.COM', // Different case
            'password' => 'password123',
            'password_confirmation' => 'password123',
        ]);

        $response->assertStatus(422)
                ->assertJsonValidationErrors(['email']);
    }

    /** @test */
    public function user_can_verify_email_with_valid_token()
    {
        $user = User::factory()->create([
            'email_verified_at' => null,
            'email_verification_token' => 'valid-token-123',
        ]);

        $response = $this->getJson("/api/verify-email/valid-token-123");

        $response->assertStatus(200)
                ->assertJson(['message' => 'Email verified successfully']);

        $user->refresh();
        $this->assertNotNull($user->email_verified_at);
        $this->assertNull($user->email_verification_token);
    }

    /** @test */
    public function email_verification_fails_with_invalid_token()
    {
        $response = $this->getJson("/api/verify-email/invalid-token");

        $response->assertStatus(400)
                ->assertJson(['error' => 'Invalid token']);
    }
}

Step 2: Watch Tests Fail (Red Phase)

Run your tests: php artisan test tests/Feature/UserRegistrationTest.php

They'll fail spectacularly. Good! That's exactly what we want.

Step 3: Write Minimum Code to Pass (Green Phase)

// UserController.php
class UserController extends Controller
{
    public function register(Request $request)
    {
        $request->validate([
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users,email',
            'password' => 'required|string|min:8|confirmed',
        ]);

        $user = User::create([
            'name' => $request->name,
            'email' => strtolower($request->email), // Handle case sensitivity
            'password' => Hash::make($request->password),
            'email_verification_token' => Str::random(60),
        ]);

        Mail::to($user->email)->send(new VerificationEmail($user));

        return response()->json(['message' => 'User registered successfully'], 201);
    }

    public function verifyEmail($token)
    {
        $user = User::where('email_verification_token', $token)->first();

        if (!$user) {
            return response()->json(['error' => 'Invalid token'], 400);
        }

        $user->update([
            'email_verified_at' => now(),
            'email_verification_token' => null,
        ]);

        return response()->json(['message' => 'Email verified successfully']);
    }
}

Step 4: Refactor with Confidence

// Let's move the logic to a service class for better organization
class UserRegistrationService
{
    public function register(array $data): User
    {
        $user = User::create([
            'name' => $data['name'],
            'email' => strtolower($data['email']),
            'password' => Hash::make($data['password']),
            'email_verification_token' => Str::random(60),
        ]);

        $this->sendVerificationEmail($user);

        return $user;
    }

    public function verifyEmail(string $token): ?User
    {
        $user = User::where('email_verification_token', $token)->first();

        if (!$user) {
            return null;
        }

        $user->update([
            'email_verified_at' => now(),
            'email_verification_token' => null,
        ]);

        return $user;
    }

    private function sendVerificationEmail(User $user): void
    {
        Mail::to($user->email)->send(new VerificationEmail($user));
    }
}

// Updated Controller
class UserController extends Controller
{
    public function __construct(private UserRegistrationService $registrationService)
    {
    }

    public function register(Request $request)
    {
        $validated = $request->validate([
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users,email',
            'password' => 'required|string|min:8|confirmed',
        ]);

        $this->registrationService->register($validated);

        return response()->json(['message' => 'User registered successfully'], 201);
    }

    public function verifyEmail($token)
    {
        $user = $this->registrationService->verifyEmail($token);

        if (!$user) {
            return response()->json(['error' => 'Invalid token'], 400);
        }

        return response()->json(['message' => 'Email verified successfully']);
    }
}

See what happened here? We refactored our code, made it cleaner and more maintainable, and our tests still pass! That's the magic of TDD.

Why TDD Will Save Your Sanity (And Your Career)

Let me tell you why TDD isn't just another buzzword that will fade away next month:

1. Fewer Bugs in Production

When you write tests first, you're forced to think about edge cases before they bite you. That case-sensitivity email bug? Caught before deployment.

2. Better Code Design

Writing tests first forces you to design your code for testability. This usually means better separation of concerns, cleaner interfaces, and more maintainable code.

3. Confidence to Refactor

Remember how we refactored our controller? Without tests, that would have been terrifying. With tests, it's just Tuesday.

4. Documentation That Never Lies

Your tests serve as living documentation. Want to know how the registration system works? Read the tests. They never lie because if they did, they'd fail.

5. Faster Development in the Long Run

Yes, you heard that right. While you might feel slower initially, TDD actually speeds up development because you spend less time debugging and more time building features.

The Real Advantages That Will Make You a TDD Convert

Advantage #1: Sleep Better at Night

When your test suite has 90%+ coverage and all tests are green, you can deploy on Friday evening without breaking into a cold sweat.

Advantage #2: Easier Team Collaboration

New team member joins? They can understand and contribute to your codebase by reading and running tests. No more "How does this work?" Slack messages.

Advantage #3: Regression Prevention

Found a bug? Write a test that reproduces it, fix the bug, and now you have a guard against that bug ever returning.

Advantage #4: Better Architecture

TDD naturally leads to SOLID principles. You'll find yourself writing more modular, testable, and maintainable code without even trying.

Getting Started with Laravel TDD (The Right Way)

Set Up Your Testing Environment

# Make sure you have PHPUnit configured
composer require --dev phpunit/phpunit

# Set up a separate testing database
cp .env .env.testing
# Edit .env.testing to use a different database

Start Small

Don't try to TDD your entire application on day one. Pick one feature, maybe a simple CRUD operation, and try the TDD approach. Get comfortable with the Red-Green-Refactor cycle.

Use Laravel's Testing Tools

Laravel gives you incredible testing tools out of the box:

// Database testing
use RefreshDatabase;

// HTTP testing
$this->postJson('/api/endpoint', $data);

// Mocking
Mail::fake();
Queue::fake();
Storage::fake();

// Assertions
$this->assertDatabaseHas('table', $data);
$response->assertStatus(200);

Write Meaningful Test Names

Instead of test_registration(), write user_can_register_with_valid_data(). Your future self will thank you.

The Bottom Line

Look, I get it. TDD feels like extra work at first. You're already busy shipping features, fixing bugs, and dealing with that legacy code that makes you question your career choices. But here's the thing, TDD isn't about writing more code, it's about writing better code.

When you embrace TDD, you're not just writing tests. You're having a conversation with your code, designing better systems, and building applications that you can be proud of. You're becoming the developer who ships features that work, who can refactor without fear, and who actually enjoys Monday mornings because you know your code is solid.

So, are you ready to give TDD a shot? Start small, be patient with yourself, and remember - every senior developer you admire probably went through the same learning curve you're about to embark on.

Trust me, once you experience the confidence that comes with a green test suite, you'll never want to go back to the old way of doing things. Your code will thank you, your team will thank you, and most importantly, you'll thank yourself.

If you found this helpful, you should probably start with testing one small feature today. Don't overthink it, just pick something simple and write your first test. You've got this!

Now go write some tests! 🧪✨

My purpose is not to teach you how to lie in an interview. It is only to leverage the interview to show your specific skill-set and to give you a chance if you truly belong.

One thing to remember! The person who asks questions, controls the interview. Always try to keep the ball on your court without giving it to the interviewer.

Let's jump in and see what we can learn today!

Ever found yourself in an interview wishing you could just nudge the questions toward the topics you’re prepared to shine in? The good news is, you actually can. It's not about manipulation; it's about guiding the conversation. Think of it like being a strategic conversationalist, skilfully leading the dialogue into areas where you can bring your A-game.

1. Set the Stage Early: Plant Seeds in Your Resume and Cover Letter

Have you watched the movie Inception? The movie tells you the value of planting something inside someones mind. The interview actually starts well before you step into the room or join the video call. Your resume and cover letter are your first chance to set the tone and plant seeds. Instead of listing responsibilities in a bland manner, highlight achievements and projects that showcase your best skills. Frame them in a way that teases the interviewer’s curiosity.

For example, instead of saying, “Managed a team of 10,” you could say, “Led a cross-functional team of 10 to complete a high-stakes project that resulted in a 30% increase in customer retention.” This approach not only shows your leadership skills but also invites a follow-up question about the details of that project.

2. Turn Every Question into an Opportunity to Tell a Story

Interviewers love stories because they provide context, emotion, and a deeper understanding of your experience. Come prepared with 3-4 stories that highlight your key strengths and align with the job’s requirements. When asked a question, no matter how far it seems from your preferred topic, find a way to link your answer back to one of these stories.

Let’s say you’re asked about handling conflict in a team. You might start with a direct answer, but quickly segue: “That’s a great question. One of the most challenging situations I faced was when I was leading a team through a major product launch. There were significant conflicts about resource allocation, but it also allowed me to use my skills in data analysis to provide objective insights that ultimately helped us make informed decisions…”

Now, you’ve turned a question about conflict resolution into a conversation about your leadership and data skills, subtly nudging the interviewer toward areas where you feel most comfortable.

3. Use the Power of the Intriguing Pause

This is a trick borrowed from great storytellers and public speakers. When you mention something compelling, pause briefly. For example: “During my time at Banana Island, I led a project that fundamentally changed our approach to customer engagement…” Pause. This brief pause creates a moment of anticipation. The interviewer is likely thinking, “What was the change?” or “How did you do it?” and will naturally ask a follow-up question.

4. Drop Curiosity Bombs: Create Hooks to Reel Them In

Another effective strategy is to drop what I call “curiosity bombs.” Mention something fascinating without fully explaining it. For example: “Oh, and that reminds me of the time I implemented an unconventional strategy that saved us nearly $500,000…” Most interviewers will be too intrigued to let that slide without asking you to elaborate.

The trick here is to make sure your curiosity bombs are relevant to the role you're applying for. They should be tailored to the skills or experiences you want to highlight, creating a natural bridge to deeper discussion.

5. Mirror Their Style and Language

Have you met someone who has a same vibe as you? People tend to feel more comfortable and engaged when they’re interacting with someone who mirrors their communication style. Pay attention to the interviewer’s tone, pace, and choice of words. If they’re using industry-specific jargon, mirror that language. If they’re casual, don’t hesitate to drop the formality a notch.

Mirroring creates a sense of rapport and makes the interviewer more inclined to stay on topics that align with both your comfort zone and theirs. It’s subtle, but powerful.

6. Turn Weakness Questions to Your Advantage

One question you’re almost guaranteed to face is the dreaded, “What’s your biggest weakness?” This is a golden opportunity to pivot to your strengths. For example, “One area I’m working to improve is delegation. I’ve always been someone who dives deep into projects, especially when they involve data analysis or strategy. I realised I was taking on too much myself and not letting my team members showcase their strengths…”

What you’ve done here is mention a “weakness” while immediately bringing the conversation back to your expertise in data analysis or strategy, areas where you want the focus to be.

7. Ask Questions That Steer the Conversation Back to Your Strengths

At some point, you’ll be asked, “Do you have any questions for us?” Don’t waste this opportunity. Prepare questions that subtly steer the discussion back to your key skills and experiences.

For example: “I noticed from the job description that you’re looking for someone to help streamline operations. Could you tell me more about what that involves? I recently led an initiative that reduced our time-to-market by 20% through a new process I developed…” Now, you’re not only expressing interest but also opening the door for them to ask how you achieved that.

8. Use Body Language to Reinforce Your Points

Body language plays a huge role in communication. When you mention a topic where you’re confident, lean slightly forward, maintain eye contact, and show enthusiasm with your facial expressions. When discussing something less favourable, keep your body relaxed and your gestures open. This non-verbal cueing helps guide the interviewer’s attention and can subtly influence which topics they dwell on.

9. Reframe the Question if It’s Off-Target

Sometimes you’ll get a question that feels completely off-base. Instead of panicking, reframe it: “That’s an interesting question. In my experience, a more relevant consideration might be…” Then, steer it towards a topic where you can shine. For example, if asked about a technology you’re less familiar with, pivot to discuss how quickly you’ve picked up new technologies in the past and your passion for continuous learning.

10. Use Your Close: Summarise Your Strengths with Purpose

As the interview draws to a close, you usually get a chance to make a final statement. Don’t let this slip by! This is your moment to summarise your key strengths and leave a lasting impression.

Something like: “I really appreciate the chance to speak with you today. I hope I’ve been able to show that I’m not only passionate about data-driven decision-making but also experienced in leading teams through complex challenges, from product launches to strategic shifts in customer engagement. I’m particularly excited about the opportunity to bring these skills to your team and help drive forward the innovative work you’re doing.”

11. Understand the Interviewer’s Underlying Needs

Most interviewers are trying to solve a problem, they need someone who can fill a role, address gaps, or drive growth. Make it your job to understand what those underlying needs are. If you sense they’re particularly concerned about a specific area, tailor your responses to address that concern directly. For example, if they’re worried about team dynamics, emphasise your experience in building cross-functional teams and navigating conflict. This approach will naturally guide them to ask more about the areas where you excel.

12. Be a Conversational Ninja: Stay Present and Flexible

Lastly, while it’s important to have a plan, you also need to stay present and flexible. Don’t be so fixated on steering the conversation that you miss the chance to respond genuinely to what’s happening in the moment. Being present allows you to pick up on subtle cues from the interviewer and adjust your tactics accordingly. If you notice they’re excited or leaning in when you talk about a particular topic, lean into that. Be ready to adapt, improvise, and find new ways to keep the conversation aligned with your strengths.

Article too long? You are almost at the end.

Remember, this isn’t about controlling the conversation; it’s about guiding it with intention. It’s about making sure the interviewer walks away with a clear picture of your best self. The more you practice, the more these techniques will become second nature.

So, the next time you step into an interview, remember: you have the power to subtly influence the direction of the conversation. Go in prepared, confident, and ready to guide the dialogue to your strengths.

As always, Good Luck!

Joining a new company is an exciting moment. You get to meet new colleagues, you get to jump into a new world and you are definitely getting a new codebase. If you did not handle or manage your excitement properly, you will end up in a situation where you get exhausted. On the initial dates, you will be getting into multiple meetings with people in different teams, and HODs and you will get to know the company culture. There will be an introductory program where they introduce you to the company. At the same time (I hope so), you will get your equipment set up for the WAR.

Most probably you were sailing smoothly in your previous company where you were in your comfort zone, but now, everything is different. New technologies, new equipment, new methods and practices (Oh, I am getting goosebumps). So, again, how would you make the most out of it in the initial stages? How could I know? I am not a person who can read minds. But, I will give some tips here about what should you do.

Be patient, but not too patient

After your team-level onboarding, you will get information about your project and your responsibilities with the role. There will be a senior member or a person who has more experience in the same domain than you (unless you hop on to the director board as a senior) as a contact point to get all the help you needed.

It is tempting for a developer to gain access to the code base and instantly begin traversing it. However, as a novice, your concentration should be broad. There are a few things you should strive to understand before implementing or altering anything at the code level.

Do not get overwhelmed with the work you have as a beginner, and you should be patient about the work you are getting into. Most of the things, you would not be able to understand at this point. That does not mean you will not understand. Do not try to grasp everything you see at first. Make a simple to-do list of your role and responsibilities.

Read the bloody documentation

I know most of you do not like to read the documentation, but it is a must if you are joining a new company.

To start, identify all the tools that your team uses to document design decisions, high-level architecture, service-level architectures, domain knowledge, and more. It's important to locate the primary source of truth for this information, as it may be stored in multiple tools with slight variations. To make it easier to find what you're looking for, create folders in your bookmarks and organize the relevant links by category. By creating this mental map, you'll know where to go when you have questions or need to reference something.

There might be many documents written by your teammates for every aspect of your project. In this case, get in touch with the senior and try to prioritize the list before jumping in.

I suggest you read product documentation before jumping into technical ones because you would not be able to understand the codebase without domain knowledge. Get in touch with a product owner if they have one, to get a broader understanding of the project you are working on. They will be able to show you the product flow including the domain knowledge, use cases and everything. Remember, whatever you do, DOMAIN KNOWLEDGE IS A MUST!

Have you heard about The C4 model for visualising software architecture?

The C4 model is a visual language for documenting software architecture. It provides a way to describe the structure, relationships, and interactions between software systems clearly and concisely. The model is made up of four layers:

1. Context: This layer shows the external factors that affect the system, such as users, devices, and other systems.

2. Containers: This layer represents the runtime environments where code is executed, such as web servers, databases, and so on.

3. Components: This layer shows the high-level components that make up the system, such as modules, libraries, and APIs.

4. Code: This layer represents the actual code that runs within the system.

A C4 model is a useful tool for communicating software architecture to stakeholders, as it provides a common language and a visual representation of the system. It can also help teams to design and evolve their systems in a structured and deliberate manner.

Getting your first task

Getting your first task in a software company can be an exciting and challenging experience. It may be intimidating to start working on real projects and contributing to the company's product or service, but it can also be a great opportunity to learn and grow as a software developer. Here are some tips for tackling your first task in a software company.

• Make sure to get a smaller task as your first task.

• Take the time to understand the problem you are trying to solve and the requirements for the task.

• Break the task down into smaller, more manageable pieces.

• Ask questions if you are unsure about anything.

• Communicate regularly with your team and stakeholders.

• Don't be afraid to ask for help or clarification when you need it.

Overall, it's important to stay focused, stay organized, and stay positive as you work on your first task in a software company. By doing your first task, you will be able to grasp more knowledge about your domain and the project. Keep learning from your tasks and eventually, you will be able to understand most of your system.

You are a new joiner, of course, mistakes and estimation issues can happen. But make sure you learn something from your mistakes and never let it happen twice.

Make sure you are a team player

Being a good team player is an important quality to have in any workplace or group setting. Make improvements within the team. Give them ideas. Help them to solve problems. Being a team player is not an easy task. You should be committed to the team. Here is how you can become a good team player (if you already do not know).

• Communicate effectively: Make sure to listen to others and share your ideas and thoughts. This can help to create a collaborative and productive team environment.

• Be respectful: Treat others with kindness and respect, even if you disagree with them. This can help to create a positive team dynamic.

• Be dependable: Follow through on tasks and commitments, and be reliable. This helps to build trust within the team.

• Be open-minded: Consider others' perspectives and be willing to try new approaches. This can lead to more innovative and effective solutions.

• Be proactive: Take initiative and be willing to pitch in where needed. This can help the team to accomplish its goals more efficiently.

• Be flexible: Be open to change and be willing to adapt to new situations. This can help the team to be more agile and responsive.

This is a good opportunity to showcase yourself to the team. There are plenty of ways to contribute to the team. Be creative and efficient.

Communication is the key

Even though you are a super competitive developer, if you cannot express your ideas or communicate with the team, all your skills will get wasted. Communication is a must for a productive team. Communication does not mean that you should be super fluent in English or any other language.

Effective communication is essential for a group to function efficiently and achieve its goals. When team members can communicate openly and honestly, it helps to build trust and facilitate problem-solving and decision-making. Good communication can also help to prevent misunderstandings and conflicts within a group. When team members can clearly express their thoughts and ideas, it can help to avoid misunderstandings and build a positive team dynamic. In addition, effective communication can help to foster a sense of community and belonging within a group. When team members are able to share their ideas and feelings with each other, it can create a stronger sense of connection and solidarity.

Now you already know what I have done to make my first weeks successful. There are no secrets or magic. Especially, make sure to be yourself in your new workplace.

If you have more to add, feel free to add them in the comment section. So, the new joiners can follow.

Oh, I forgot. Congratulations on your new job!

See you again on another topic.

Cheerio!

Hey everyone. I am back with another design pattern. If you are new to the blog and willing to learn design patterns, you can find the explained design patterns in this series.

Have you heard about Banana Man? Of course not. That is a character in my world, The Banana Republic. Unlike other characters, this Banana Man sometimes acts as a Super Hero and as well as a Super Villain. Also, he travels among the people as just a normal person while hiding his true identity from the world (Of course I know who he is. But I won't tell you 🤐).

Did you ever think about how he manages to change his identity or the STATES? No, because you are so selfish, you only think about yourself. JK!

Let's see how this Banana Man manages to change the states according to the work he has been assigned to.

Let's look at the below code.

class BananaMan
{
    public function __construct($state)
    {
        if ($state == 'hero') {
            // Do hero stuff.
        } else if ($state == 'villain') {
            // Do villain stuff.
        } else if ($state == 'human') {
            // Blend with normal people.
        } else {
            // I do not know. I just put else because I thought it would be nice.
        }
    }
}

// Ha! I see some villains.
$bananaMan = new BananaMan('hero');

// Heroes are taking over the world. I should be a super villain.
$bananaMan = new BananaMan('villain');

// I am tired. I will just walk on the street and blend.
$bananaMan = new BananaMan('human');

See how easily he changes his identity. Was this hard? NOPE! So, what were you afraid of?

Hmm! I do not know. Maybe he has to change himself all over again if there was another state of himself. Like a prince maybe?

EXACTLY! If he gets another state (as you mentioned, a prince state. A prince superhero? Good thought for a Disney movie) he has to change his core-self (what I meant by that is to change the base class. Sigh!). So, it would be hard to maintain. How do we make this more maintainable?

Base class changes can lead to multiple issues like broken logic that was implemented previously.

Let's see how we can manage the situation with a design pattern.

For starters, I'll create an interface for Banana Man's states.

interface BananaState
{
    public function doYourThing();
}

Now let's create Banana Man's different states as classes.

class SuperHero implements BananaState
{
    public function doYourThing()
    {
        // Do hero stuff.
    }
}

class SuperVillain implements BananaState
{
    public function doYourThing()
    {
        // Do villain stuff.
    }
}

class Human implements BananaState
{
    public function doYourThing()
    {
        // Blend with normal people.
    }
}

What I have simply done here is, create separate classes for the states by implementing interface BananaState . After implementing interface BananaState , I have to override the function doYourThing() because it has been defined in the interface. Then inside doYourThing() , I would implement the logic that needs to be done in these different states.

Now, to the base class.

class BananaMan
{
    private $state;

    public function __construct(BananaState $state)
    {
        $this->state = $state;
    }

    public function setState(BananaState $state)
    {
        $this->state = $state;
    }

    public function changeState()
    {
        $this->state->doYourThing();
    }
}

Here, I have created the BananaMan class, and there I created a constructor with a parameter of interface BananaState . Once, you pass your state to the constructor, it will get assigned to the global $state variable and you can use the variable inside the base class to change the state. setState() is to change the state without creating an object again. changeState() is to trigger the state change that was assigned through the constructor.

By doing this, whenever you add a state, the base class remains unchanged. So, you can add or remove statuses as you wish without touching the base class.

// I am walking as a normal person.
$bananaMan = new BananaMan(new Human);
$bananaMan->changeState();

// Hm! That guy stole the purse of that innocent lady. Time to be a Super Hero.
$bananaMan->setState(new SuperHero);
$bananaMan->changeState();

// I am just bored. It is time to play with the cops.
$bananaMan->setState(new SuperVillain);
$bananaMan->changeState();

See how easily he changes his identity for his different states? Here, if he wanted to be a prince, he can be without touching his core (the base class). The only thing you need to do is create a new class for his new identity and implements it with the interface, and call changeState().

This design pattern is called the State Design Pattern. Because it allows you to change the state of an object without touching the base class. This is highly maintainable and very easy to use.

Usage of this design pattern

• Handling state transitions: The state design pattern may be used to handle an object's state transitions, such as switching from one state to another based on particular criteria.

• Simplifying complex code: By enclosing state-specific activity in distinct classes, the state design pattern can assist to simplify complex code, making it easier to understand and maintain.

• Changing behaviour at runtime: The state design pattern enables an object to alter its behaviour at runtime by swapping out its state object instead than modifying the object itself.

• Decoupling behaviour from implementation: The state design pattern separates the implementation of distinct states into independent classes, making it easier to alter or add new states without impacting existing behaviour.

Real-life examples of the pattern

• Traffic lights: A real-world example of the state design pattern is traffic lights. A traffic light can be in one of three states: red, yellow, or green. The traffic light's behaviour (i.e., the colour it shows) is determined by its internal status.

• Elevator: Another example of the state design pattern is an elevator. An elevator can be in three states: going up, travelling down, and idle. The present state of the elevator determines its behaviour (e.g., the level it stops on, whether it travels up or down).

• Automated teller machine (ATM): A nice illustration of the state design pattern is an ATM. An ATM can be in several states, including idle, processing a transaction, and distributing cash. The present state of the ATM determines its behaviour (for example, which options it offers to the user).

• Music player: A music player can be in numerous states, including playing, pausing, and stopping. The current state of the music player determines its behaviour (e.g., whether it plays or pauses music).

  See how you have already used this concept without knowing?

  What can you see in a design pattern like this?

• Context: The context is the object that maintains a reference to the current state object and delegates state-specific behaviour to the state object.

• State: The state is an interface that defines the behaviour that each state must implement.

• Concrete states: Concrete states are classes that implement the behaviour defined in the state interface. Each concrete state represents a different state of the context.

• Client: The client is the code that uses the context and state objects.

That is it for the State Design Pattern. Will come to you with another design pattern very soon.

Till then, then.

In this article, I am going to talk about some PHP Interview Questions that will hit you hard until you fell. If you are going to face an interview for a senior or above position, you should have to have an understanding of the below questions.

Ready to get hit? Let's go!

What is Late Static Binding?

Late static binding in PHP refers to the ability to reference a class using the static keyword. When you use static to refer to something like a class, PHP will utilize the class that was called at runtime rather than the class that was called at compile time. This allows you to write methods in a base class that may be overridden by derived classes and have the right method called depending on the situation.

In PHP, here's an example of late static binding:

Imagine you have a class called Animal, which has a method called makeNoise(). This method simply outputs the sound that the animal makes:

class Animal {
    public static function makeNoise() {
        echo "Grrrr...";
    }
}

Now, let's say you want to create a subclass of Animal called Dog, which should override the makeNoise() method to output a different sound. You can do this using late static binding:

class Dog extends Animal {
    public static function makeNoise() {
        echo "Woof woof!";
    }
}

Now, whenever you call Dog::makeNoise(), it will output "Woof woof!", because the makeNoise() method of the Dog class is called at runtime.

But let's say you also have a class called Cat, which should make a different noise when it's makeNoise() method is called:

class Cat extends Animal {
    public static function makeNoise() {
        echo "Meow!";
    }
}

If you call Cat::makeNoise(), it will output "Meow!", because the makeNoise() method of the Cat class is called at runtime.

So, in this example, the late static binding allows different animals to make different noises, depending on which class was called at runtime.

Reasons to use Late Static Binding (LSB).

• Overriding static methods: LSB allows you to override static methods in a subclass while still utilizing the parent:: syntax to call the parent method. This is handy if you have a parent class with a static method that should be overridden in a child class, but you want to make sure that the child class method gets called even if the parent method is accessed via a static context.

• Polymorphism: With LSB, you may write polymorphic static methods that behave differently based on the class that is called at runtime. This is handy if your base class has a static function that should be implemented differently in each subclass.

• Dynamic context: In a static context, you can use the static:: syntax to refer to the called class rather than the class where the method is declared. This is handy if you wish to utilize a static method in a dynamic situation where the class being called is unknown until runtime.

• Code simplification: LSB may help you simplify your code by avoiding the need for conditional statements to establish the context of a static method. Instead, you may use the static:: syntax to automatically reference the called class.

You already knew it! I know. But were you able to explain it?

What is a ReflectionClass in PHP?

This is where you get the headshot immediately. Did you hear about this class before? Did you know that this class was there since PHP 5?

In PHP, the ReflectionClass class is a part of the Reflection API, which allows you to introspect classes, interfaces, and traits in your PHP code.

Using the ReflectionClass class, you can get information about a class, such as its name, the names of its methods and properties, and its parent class. You can also use it to instantiate an object of a class, or to check if a class is abstract or final.

class TheNewGameThatIamBuilding {
    public $ammo;
    protected $health;
    private $lives;

    public function shootOnTheSpot() {}
    protected function runWhenSeeAnEnemy() {}
    private function getPumpedUp() {}
}

$reflector = new ReflectionClass('TheNewGameThatIamBuilding');

// Get the class name
echo $reflector->getName() . "\n";

// Check if the class is abstract
echo $reflector->isAbstract() . "\n";

// Get a list of properties
$properties = $reflector->getProperties();
foreach ($properties as $property) {
    echo $property->getName() . "\n";
}

// Get a list of methods
$methods = $reflector->getMethods();
foreach ($methods as $method) {
    echo $method->getName() . "\n";
}

// Create new instance
$instance = $reflection->newInstance();

In this example, the ReflectionClass object is created for the TheNewGameThatIamBuilding class, and then various details about the class are extracted using various methods of the ReflectionClass class.

The ReflectionClass class is useful for creating class introspection tools, for debugging, or for creating generic code that can work with any class.

There are many more functions in this ReflectionClass, you can check from php.net

What is the difference between empty, isset and array_key_exists?

empty

As the name suggests, empty checks whether the variable is empty. The below values are acceptable in PHP as empty.

• NULL

• FALSE

• array()

• 0.0

• "0"

• 0

• ""

isset

isset can be used when you want to determine if a key exists and is associated with a value. When the array key exists but the value is null, isset will return false .

array_key_exists

array_key_exists will tell you when a certain key exists inside an array. When the array key exists but the value is null, array_key_exists will return true.

When comparing the performance, isset is faster than array_key_exists because it is actually a language construct, not a function. But the performance is negligible unless you are doing some Jimmy Neutron stuff.

What are variables passing as values and passing as references?

In PHP, when you pass a value (such as a scalar value or an object) to a function or method as an argument, it is passed by value by default. This means that a copy of the value is passed to the function, and any changes made to the value inside the function have no effect on the original value outside the function.

Here is an example of passing a value by value in PHP:

function incrementValue($value) {
    $value++;
}

$x = 10;
incrementValue($x);
echo $x; // Outputs: 10

The value of $x is supplied as an argument to the incrementValue() method in this example. The value of $value is increased by one throughout the function. This modification, however, has no effect on the original value of $x since $value is a copy of $x and the original value of $x remains unchanged.

If you wish to provide a value to a function via reference, however, you may use the & operator in the function specification. This instructs PHP to send a reference to the original value rather than a copy of the value to the function. Any modifications made to the value within the function will be mirrored in the original value outside the function.

function incrementValue(&$value) {
    $value++;
}

$x = 10;
incrementValue($x);
echo $x; // Outputs: 11

In this example, the & operator is used to send the value of $x as an argument to the incrementValue() method. The value of $value is increased by one throughout the function. Because $value is a reference to the original value of $x, when the original value is updated, this change is reflected in the original value of $x.

What is composer, difference between composer install and composer update, and what are the other functionalities of composer

If you are a PHP developer, you must know about the functionality of composer. Let's answer the questions one by one.

What is composer?

Composer is a PHP dependency management tool. It allows you to define the libraries on which your project depends and manages (installs/updates) them for you.

Composer is not a package manager like YUM , APT or BREW . The composer handles packages on a project basis. When you install dependencies through composer, it will download all the packages to a /vendor folder inside the project root. However, it does support global functionalities if you install it as global.

Difference between composer install and update

Before that, have you seen there are two files in the project called composer.json and composer.lock?

Basically, the composer.json file includes the project dependencies that is needed for the project development. Unless you remove something from composer.json it will always get installed on the development project whenever you run composer update.

When installing your project for the first time or upgrading, composer.lock is produced. It includes references to the particular versions that were utilized. It should be committed to the version tracking repository so that this precise mix of libraries may be restored.

Okay, to the question about composer install and composer update.

Imagine you are doing the developments on a local or a development server. You have some project dependencies that need to be updated. Then you run composer update . So all the dependencies will get updated according to the composer.json file and will save the updated dependency details in the composer.lock file. Once you run composer update it will,

• Read composer.json

• Remove installed packages that are no more required in composer.json

• Check the availability of the latest versions of your required packages

• Install the latest versions of your packages

• Update composer.lock to store the installed packages version

Imagine you are setting up the project for the first time in your local environment or the production server. Then you need to run composer install . Once you run composer install, it will do below things.

• Check if composer.lock file exists (if not, it will run composer update and create it)

• Read composer.lock file

• Install the packages specified in the composer.lock file

As an example, if you download a project such as Laravel, the first you should do is run composer install. Then it will automatically install the dependencies according to the lock file that was in the repository. After a while, you realize that you need another package to be installed. What you should do is, add that package to the composer.json file and run the composer update. It will re-read the json file and install/ upgrade your packages as defined in the json, then write-out the utilized versions on the lock file.

When you push your changes to your remote, make sure to push your lock file. Because, if not, the next person who downloads your changes will not have your updated lock file. Hence, they will miss the newly added dependency.

AND, it is a bad practice to push your /vendor directory on to the remote. Always use composer install to install your dependencies on your new environment.

What are other functionalities of composer?

• The composer may produce an autoloader for your project, allowing you to autoload PHP classes from your project and its dependencies without having to require each class file explicitly.

• Scripts: In your composer.json file, you may create custom scripts that can be performed at various stages during the Composer workflow (e.g., before or after installing or updating dependencies). This can be handy for operations like running tests, creating assets, or doing database migrations.

• Version restrictions: You may establish version constraints for your dependencies in Composer, which helps guarantee that your project only downloads and utilizes compatible versions of those dependencies.

• Virtual environments: The create-project command in Composer allows you to build a new project based on a package or template and install all of its dependencies in a single command. This might be beneficial for quickly generating development environments or launching new projects.

• Composer includes a plugin system that allows developers to expand their capabilities by creating new plugins. There are plugins available for connecting Composer with version control systems, delivering projects to servers, and producing documentation, among other things.

If you know all these answers for the questions, you are a well seasoned developer. But, if you do not know for some questions, do not be afraid. That is why there is this technique is placed called Learning, and you will be able to learn these in no-time. No one knows everything. Only this that matters is your willing-to-learn attitude.

See you soon with another topic!

Dependency Inversion Vs. Dependency Injection

Hmm sounds the same right? Yes sounds the same. But they have two different meanings. Actually, dependency injection is a technique that we can use to do dependency inversion. It involves providing the dependencies of a class through its constructor or methods, rather than the class creating or accessing them directly. This allows the dependencies to be easily swapped out or mocked for testing, and makes the class more modular and easier to test and maintain.

Something like this

class Foo {
  private final Bar bar;

  public Foo(Bar bar) {
    this.bar = bar;
  }

  public void doSomething() {
    bar.doSomethingElse();
  }
}

public foo(Bar bar) is the constructor of the class Foo . With dependency injection, Foo would accept an instance of Bar as a constructor parameter or method argument. This allows the caller to pass in a specific instance of Bar when creating an instance of Foo, making it easier to test Foo and swap out different implementations of Bar.

Now you know what is Dependency Injection. But we still did not get an answer for Dependency Inversion.

What is Dependency Inversion?

In software engineering, the dependency inversion principle is a design principle that states:

• High-level modules should not depend on low-level modules. Both should depend on abstractions.

• Abstractions should not depend on details. Details should depend on abstractions.

This principle can be applied in the context of PHP to help you design more flexible and maintainable software.

One way to implement dependency inversion in PHP is to use dependency injection. This involves creating a class that has dependencies on abstractions (e.g., interfaces) rather than concrete implementations. The concrete implementations can then be injected into the class via its constructor or setter methods, allowing the class to be more flexible and easier to test.

I hate to explain something without a code example. Let's jump into a code, shall we?

Dependency Inversion Principle explained with code

Let's assume you have to create a system to send a WhatsApp notification when a user is registered. One way to do it is as below.

class UserController {
  protected $notification;

  public function __construct() {
    $this->notification = new WhatsAppNotification();
  }

  public function register($email, $password) {
    // Register user functionality in here

    // Send notification
    $this->notification->send($email, 'Welcome!', 'Thank you for registering.');
  }
}

class WhatsAppNotification
{
    public function send($to, $subject, $body)
    {
        // Send a notification in here
    }
}

This is very cool for a while. Then suddenly your angry manager pops up and says "I also need to add Slack Notification to the system". You, the pro-developer say, "Yo! I got this man!" and change the UserController as below.

class UserController {
    protected $notification;

    public function __construct($notificationType) {
        if ("WhatsApp" == $notificationType) {
            $this->notification = new WhatsAppNotification();
        } else {
            $this->notification = new SlackNotification();
        }
    }

    public function register($email, $password) {
        // Register user functionality in here

        // Send notification
        $this->notification->send($email, 'Welcome!', 'Thank you for registering.');
    }
}

Again after a month, your manager asks you to add email notifications as well. Now you are frustrated because you have to change the class over and over again when you get a new requirement. This is a very bad practice and this can be easily solved via the Dependency Inversion Principle.

I'll remind you again what this principle says.

High-level modules should not depend on low-level modules. Both should depend on abstractions.

In this example, UserController is the high-level module. And WhatsAppNotification and SlackNotification classes are low-level modules. It basically says, when you add the functionality of these notifications, it should not get affected to the UserController class. Simple as that. So when you implement the principle, you will not have to re-change the UserController class over and over again.

Let's jump into the code and restructure it.

So, if I am doing this, what I will do is, I will (I am saying "I will" like I am the person who found this principle. Actually, that would be nice. But I did not. So, 😅😂) create an interface for these notifications and add the send() there. So, all the notification classes that implement this interface will have to override the send function.

Can I create just the classes without the interface? Then it would be hard to implement the principle. You will see why. Stay with the article.

interface NotificationInterface {
    public function send($to, $subject, $body);
}

Now the three notification classes.

class WhatsAppNotification implements NotificationInterface
{
    public function send($to, $subject, $body)
    {
        // send email using WhatsAppNotification library
    }
}

class SlackNotification implements NotificationInterface
{
    public function send($to, $subject, $body)
    {
        // send email using SlackNotification library
    }
}

class WhatEverTheHellYouNeedToImplementNotification implements NotificationInterface
{
    public function send($to, $subject, $body)
    {
        // send email using WhatEverTheHellYouNeedToImplementNotification library
    }
}

Now to the UserController. Remember we have to structure this like it has nothing to do with adding low-level classes.

class UserController
{
    protected $notification;

    public function __construct(NotificationInterface $notification)
    {
        $this->notification = $notification;
    }

    public function register($email, $password)
    {
        // Register user functionality in here

        $this->notification->send($email, 'Welcome!', 'Thank you for registering.');
    }
}

Now, what has happened? Do you remember the Dependency Injection? Injecting a class into another class's constructor. THAT HAPPENED. But, instead of a class, we have injected an interface.

WHY THE HELL IS THAT?

public function __construct(WhatsAppNotification $notification)
{
    $this->notification = $notification;
}

If we inject a class object as the above code, you will only be able to pass an object of the mentioned class. As an example, since I have mentioned WhatsAppNotification in here, I will not be able to send a SlackNotification class to the UserController 's constructor.

But, if I mention an interface instead of a class, I will be able to pass any object that implements the interface. So here (not the white-coloured code, above that), I will be able to pass WhatsAppNotification , SlackNotification or WhatEverTheHellYouNeedToImplementNotification classes into the UserController's constructor (Because all those classes implements the same interface).

I'll add the complete script again here so it is easy to explain.

interface NotificationInterface {
    public function send($to, $subject, $body);
}

class UserController
{
    protected $notification;

    public function __construct(NotificationInterface $notification)
    {
        $this->notification = $notification;
    }

    public function register($email, $password)
    {
        // Register user functionality in here

        // Send notification
        $this->notification->send($email, 'Welcome!', 'Thank you for registering.');
    }
}

class WhatsAppNotification implements NotificationInterface
{
    public function send($to, $subject, $body)
    {
        // send email using WhatsAppNotification library
    }
}

class SlackNotification implements NotificationInterface
{
    public function send($to, $subject, $body)
    {
        // send email using SlackNotification library
    }
}

class WhatEverTheHellYouNeedToImplementNotification implements NotificationInterface
{
    public function send($to, $subject, $body)
    {
        // send email using WhatEverTheHellYouNeedToImplementNotification library
    }
}

In the above code, whatever notification class you add, you only need to implement the NotificationInterface . And that notification class will easily be able to pass to the UserController class. Does not matter how many notification types you add, you do not need to change the UserController class. So, as the principle says "High-level module (aka. UserController class) will not depend on lower-level modules (aka. WhatsAppNotification , SlackNotification, WhatEverTheHellYouNeedToImplementNotification classes)".

See how you made a disastrous code into a nice maintainable one. This is the main advantage of these principles. Easily maintainable classes.

By following the dependency inversion principle, it is easier to create modular, maintainable, and testable code that is less prone to breaking when changes are made.

Okay, here it goes with the SOLID Design Principles. It took a little longer than I thought with the break I took. My bad 😥.

Complete list of SOLID principles that I have explained in this series.

Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

See you again soon then!

First of all, let's see what is an Interface.

What is an Interface?

The interface is a blueprint of a class which has all the elements that a class has to implement. Methods or functions inside an interface are called abstract functions. Those have just the function name, and not a body or functionality inside. It is just to say like "Hey! If you are implementing this interface in your class, you should override all the functions of this interface".

Let's look at the below example.

interface AnimalInterface
{
    public function move();
    public function eat();
}

class Animal implements AnimalInterface
{

    /*
        Overriding move()
    */
    public function move()
    {
        // functionalities related to move should be here.
    }

    /*
        Overriding eat()
    */
    public function eat()
    {
        // functionalities related to eat should be here
    }
}

As you can see in the above code interfaces are binding to a class through the keyword implements. Unlike extends (inheritance), multiple interfaces can be implements in a class.

What does it mean by segregation?

So, what does segregation means? Google says "the action or state of setting someone or something apart from others". It is true you know, that is exactly what we are trying to do here.

What is Interface Segregation?

The Interface Segregation Concept (ISP) is an object-oriented design SOLID principle that argues that clients should not be compelled to rely on interfaces they do not utilize. In other words, rather than having a huge and complex interface with numerous methods that may or may not be useful to the client, interfaces should be built such that customers only have access to the methods they require.

How can we break the Interface Segregation Principle? (Of course unintentionally)

Let's see what breaks the interface segregation principle. Imagine you are creating a game with three characters. A hero, a tank and a turret (Yes I know tanks and turrets are not characters. But I am creating the game. So be it).

First, let's make an interface for these characters. This contains the functions these characters can do.

/**
 * Character Interface
 */
interface Character
{
    /*
    Character moves
    */
    public function move();

    /*
    Character shoots
    */
    public function shoot();

    /*
    Charcter speaks
    */
    public function speak();
}

Now let's implement the classes to use the interface.

/**
 * Hero character
 */
class Hero implements Character
{
    /*
    @override Character moves
    */
    public function move()
    {
        echo "Move";
    }

    /*
    @override Character shoots
    */
    public function shoot()
    {
        echo "Shoot";
    }

    /*
    @override Charcter speaks
    */
    public function speak()
    {
        echo "Speak";
    }
}

/**
 * Tank character
 */
class Tank implements Character
{
    /*
    @override Character moves
    */
    public function move()
    {
        echo "Move";
    }

    /*
    @override Character shoots
    */
    public function shoot()
    {
        echo "Shoot";
    }

    /*
    @override Charcter speaks
    */
    public function speak()
    {
        throw new Exception("Cannot Speak");
    }
}

/**
 * Turret character
 */
class Turret implements Character
{
    /*
    @override Character moves
    */
    public function move()
    {
        throw new Exception("Cannot Move");
    }

    /*
    @override Character shoots
    */
    public function shoot()
    {
        echo "Shoot";
    }

    /*
    @override Charcter speaks
    */
    public function speak()
    {
        throw new Exception("Cannot Speak");
    }
}

Now, here I have created an Interface with 3 abstract functions for move, shoot and speak. A hero can do all these three, a tank can only move and shoot but cannot speak, and a turret can only shoot. This code works perfectly without any issues. But, how does it break Interface Segregation Principle?

As you can see in the code, there are lots of exceptions inside a class. Having exceptions inside a class is totally fine. But here, as you can see, there are many unwanted functions for some characters.

How can we make a class and an interface adhere to Interface Segregation Principle?

Now let's see how we can adhere to the principle with the same code.

First, what I would do is, instead of creating a single interface for all three functions, I will create three separate interfaces.

/**
 * CharacterMoves Interface
 */
interface CharacterMoves
{
    public function move();
}

/**
 * CharacterShoots Interface
 */
interface CharacterShoots
{
    public function shoot();
}

/**
 * CharacterSpeaks Interface
 */
interface CharacterSpeaks
{
    public function speak();
}

Then I will implements only the needed interfaces in the classes.

/**
 * Hero character
 */
class Hero implements CharacterMoves, CharacterShoots, CharacterSpeaks
{
    /*
    @override Character moves
    */
    public function move()
    {
        echo "Move";
    }

    /*
    @override Character shoots
    */
    public function shoot()
    {
        echo "Shoot";
    }

    /*
    @override Charcter speaks
    */
    public function speak()
    {
        echo "Speak";
    }
}

/**
 * Tank character
 */
class Tank implements CharacterMoves, CharacterShoots
{
    /*
    @override Character moves
    */
    public function move()
    {
        echo "Move";
    }

    /*
    @override Character shoots
    */
    public function shoot()
    {
        echo "Shoot";
    }
}

/**
 * Turret character
 */
class Turret implements CharacterShoots
{
    /*
    @override Character shoots
    */
    public function shoot()
    {
        echo "Shoot";
    }
}

As you can see here, there is no need to add the exceptions. Because the class only contains the functions that it is supposed to use. Turrets cannot move nor speak, so it does not have a need to use those functions. So, we kept the interfaces apart from each other so we do not need to use unwanted functions inside a class.

This is the base of the Interface Segregation Principle. Keeping interfaces simple and apart from each other.

Advantages of Interface Segregation Principle

1. Improved flexibility: By building smaller, more focused interfaces, you can update or extend the interfaces more readily without hurting customers that rely on them. This makes it easy to make changes to your codebase without affecting current functionality.

2. Better cohesion: Interfaces created with the ISP in mind are more coherent since they only offer methods relevant to a certain client. This results in code that is easier to maintain and comprehend.

3. Improved readability: It might be difficult to comprehend the relationships between different components when dealing with a huge codebase. Following the ISP can help you understand how various components communicate with one another because each interface only provides methods that are relevant to a given client.

4. Reduced complexity: You may minimize the complexity of your codebase and make it easier to understand and maintain by building interfaces that are suited to individual clients.

Overall, following the Interface Segregation Principle can help you design more flexible, maintainable, and understandable code in PHP.

It is for the day then. Hope you enjoyed and learned something from this article. Keep in touch with the blog to see the next article on the final SOLID principle. That is Dependency Inversion Principle.

Complete list of SOLID principles that I have explained in this series.

Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Laters gaters!

What should we consider when scoping a project (In theory)

Scoring a project in software engineering involves several key steps:

1. Define the project goals and objectives: The first step in project scoping is to establish a clear understanding of what the project is attempting to accomplish. Identifying the business needs or problems that the project is intended to solve, as well as any specific requirements or constraints that must be met, may be part of this process.

2. Identify the stakeholders: It is critical to identify all stakeholders who will be affected by the project as well as those who will be held accountable for its success. The project sponsor, project team, end users, and any other parties with an interest in the project may be included.

3. Define the project scope: Once the project goals and objectives have been established, as well as the stakeholders, the next step is to define the project scope. This could entail identifying the specific features and functionalities that will be included in the project, as well as any constraints or limitations that must be taken into account.

4. Develop a project contract: A project charter is a document that outlines the project's key details, such as the project goals and objectives, project scope, stakeholders, and resources needed to complete the project. Throughout the project, the project charter serves as a reference point, ensuring that all stakeholders are on the same page.

5. Establishing a timeline and budget is an important step in scoping a project because it ensures that the project can be completed within the available resources and constraints. The timeline should include key milestones and deliverables, and the budget should outline the project's costs.

6. Define the roles and duties of all project stakeholders, including the project team, the project sponsor, and any other parties that will be engaged in the project. This helps to ensure that everyone understands what is expected of them and that the project is held accountable.

7. Identify possible risks and issues: Identifying potential risks and issues is a key phase in project scoping because it ensures that the project is well-prepared to deal with any obstacles that may occur. Identifying any risks to the project timing, budget, or scope, as well as any concerns that may affect the project team or stakeholders, may be part of this.

8. As the project continues, it may be important to evaluate and amend the project scope to ensure that it stays relevant and feasible. This may entail altering the project's timeframe, budget, or scope to meet changes or obstacles that emerge.

Yes, it is a lot. What did you expect? An Ice cream?

Overall, scoping a project in software engineering includes identifying stakeholders, defining the project scope, producing a project charter, setting a timeframe and budget, defining project roles and duties, and identifying potential risks and concerns. Following these steps will ensure that a project is well-structured and well-prepared to succeed.

How do I, or what am I doing to scope and create boundaries when I get a project

1. Start taking notes: This is the most important part for me. Regardless of what I have with me, I quickly start taking notes. It could be a pen and paper, or one note. Does not matter. The only thing that matters is you taking notes about everything. It should not be a lovely-looking note. It could be an ugly-ass note that only you can understand.

2. List down the entities: This is the second important part of scoping a project. You have to list down however you can, whatever you can. As an example, if it is a project about a shopping cart you have to list down User Management (add/ update users with the roles and permissions), Product Management (add/ update products with their prices and stocks), Shopping cart and obviously a Payment Gateway.

3. Group the entities with their relationship: In here, you have to group those entities and make a relationship between them. This is where you make a rough database structure (not an ER) with the details about how the entities are getting connected and divide them into sections. After this is done, every section would become a milestone. As an example, how the users are getting permissions, what would the structure should be with permissions etc.

4. Start making diagrams: Who does not love pictures and diagrams. Start making the diagrams in this stage. There can be many diagrams. It can be use-case diagrams, flow charts, sequence diagrams or even mindmaps. The more the diagrams, the more you understand the project structure and what to do.

After you follow these steps you should be able to get a clear idea about the scope of your project and the boundaries.

There can be many methods of scoping a project. But personally, the above mentioned method suits me. There is no hard and fast rule about scoping a project. Only thing you should think about is, how well you can breakdown the structure for better understanding.

Hope this helps to you to scope your projects, personal or commercial. Comment below if you use or have used any other methods you use to scope projects.

See you soon with another topic!

Bye bye!!

The name of this principle sounds very serious. But I assure you, there is nothing to be scared of. This is a very simple principle with a scary name. The person who found this principle was Barbara Liskov. Hence the name Liskovs Principle.

What is Liskov Substitution Principle?

The Liskov Substitution Principle (LSP) is a principle in object-oriented programming that states that objects of a subclass should be able to be used in the same way as objects of the superclass, without the user of the objects needing to be aware of the difference. This means that any subclass of a class should be able to be used in the same way as the superclass, without affecting the correctness of the program.

Okay, that does not help. I know. Let's see what it really means.

It means when you have sub-classes, it should be able to use as the parent class. I know, I know. That does not help too. Let's jump into a code, so you can understand better.

In PHP, this principle can be applied by following some best practices when designing your class hierarchy. Here is an example of how you can apply the Liskov Substitution Principle in your PHP code:

Consider a simple example where we have a Shape class and two subclasses: Rectangle and Square.

class Shape {
    public function area() {
        // code to calculate the area of the shape
    }
}

class Rectangle extends Shape {
    public $width;
    public $height;

    public function __construct($width, $height) {
        $this->width = $width;
        $this->height = $height;
    }

    public function area() {
        return $this->width * $this->height;
    }
}

class Square extends Shape {
    public $sideLength;

    public function __construct($sideLength) {
        $this->sideLength = $sideLength;
    }

    public function area() {
        return $this->sideLength * $this->sideLength;
    }
}

In this example, we have a Shape class with a single method, area(), which calculates the area of the shape. We also have two subclasses: Rectangle and Square. The Rectangle class has two properties: width and height, and the Square class has a single property: sideLength.

To apply the Liskov Substitution Principle in this example, we need to ensure that the Rectangle and Square classes can be used in the same way as the Shape class. This means that the area() method of the Rectangle and Square classes should have the same signature and return type as the area() method of the Shape class.

We can see that this is the case in the example above. The area() method of the Rectangle class takes no arguments and returns an integer, which is the same as the area() method of the Shape class. Similarly, the area() method of the Square class also takes no arguments and returns an integer.

By following this approach, we can ensure that our Rectangle and Square objects can be used in the same way as Shape objects, without the user of the objects needing to be aware of the difference. This makes our code more flexible and easier to maintain over time.

Advantages of Liskov Substitution Principle

The Liskov Substitution Principle (LSP) is important because it helps to ensure that a program is well-structured and easy to understand and maintain. By adhering to the LSP, developers can be confident that objects of a subclass can be used in the same way as objects of the superclass, which helps to reduce the risk of introducing bugs into the program.

Additionally, the LSP can help to make it easier to extend and modify a program. For example, if a program is designed to use a superclass and its subclasses in a way that adheres to the LSP, it will be easier to add new subclasses or modify existing ones without breaking the program. This can save time and effort when developing and maintaining software and can help to reduce the overall cost of ownership of the program.

Overall, the Liskov Substitution Principle is an important principle to consider when designing and implementing object-oriented software, as it can help to ensure that the program is robust, easy to understand, and easy to maintain.

That is about it for the day. Let's meet with the next article on SOLID Principles. That is Interface Segregation Principle.

Complete list of SOLID principles that I have explained in this series.

Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Have a good day!

But, the next question would not be simple as it seems. What do you do when you get stuck at a code? Everyone might have different approaches. But since this is my article, I'll share mine 😋

A developers' life is not cool as it is advertised or as other people see. "Whoa, a cool guy with a headset and a computer". Is it actually cool? Only the developers know the answer to that question because only us know how much we scratch our heads after getting stuck at code. So, apart from scratching our heads, what we can do to get out of it?

Breath, and take a step back from your chair

Everyone needs a small break once in a while. Your brain does too. Without a little break, you beta wave activity in brain can get slightly high and it can cause you stress. Stress will definitely block your brain from generating new ideas and solutions. When you get stuck in a code, you usually think a lot about the situation and try to get out of it. But without knowing, it can get you deeper into the problem and it will make you exhausted and un-see the solution.

So, take a little break, look at your surroundings and specially make your self calm. Everyone has different ways of making themselves calm. Some needs meditation, some needs a little encouragement and some needs music or games. It actually does not matter how you make yourself calm. If you need to scream at a wall to make yourself calm, I suggest you to do it.

Make a mind map

Now, since you have calmed yourself, you can take a different approach to find the solution. Have you ever tried creating a simple mind map before doing the developments on your feature. If you have not yet, better to make a mind map now. Because there is a high chance that you find an alternate way to figure out the same problem that you are stuck right now. Just take a pen and paper, or open a OneNote.

Rubber duck debugging or Rubberducking

Rubberducking? Yep it is a word that has been created only for these kinds of situations. I have experienced the same situation, but unfortunately not with a duck. It is very simple. When you are stuck at a code, you can ask a solution from a person. When you do, you explain the situation from the beginning. Most of the times, before you complete the explanation, your light bulb will work and you will see the solution in your head. This has happened to me numerous times. Rubber duck debugging is also the same. Instead of a real person, you get a inanimate object or your favorite pet, and start explaining the situation like to a real person. Most of the times, your light bulb may work.

Take a powernap

Powernap is a quick sleep between 15 - 30 minutes. Power naps have health benefits such as improved memory, cognitive performance, and better logical reasoning. However, excessive napping can disrupt a person's circadian rhythms, leading to increased exhaustion.

After waking from a powernap, you and your brain will feel refreshed and you may get new ideas to get out your problem. Again, if you are taking a powernap, make sure to do it in less than 30 minutes.

Reading documentations

This will work only if you get stuck while integrating a 3rd party system or a library. The solution is sometimes already there in the documentation, as an alternative or an example. Check the documentation for the right version of the library. For huge libraries, I prefer to browse the full API page - occasionally the information you're searching for is there, but with a completely different name.

git bisect

You probably have not heard this before. git bisect employs a binary search method to determine which commit in the history of your project created a bug. You apply it by first giving it a "bad" commit that is believed to include the bug as well as a "good" commit that is confirmed to be prior to the introduction of the bug. Then git bisect chooses commits among these two endpoints and offers you whether it is "good" or "bad." It narrows the range more until it discovers the specific commit that caused the change.

Write a Unit Test

A unit test is written to test most basic testable component of a program, such as functions, classes, procedures, and interfaces. Individual pieces of source code are examined to see if they are fit for use, using unit testing. I you do not have a unit test, guess it is time to write one. You will be able to see what causes you to stuck at your code.

Stack Overflow

If you are in a hurry, this should be your number one. But, if you are not, this should be the last. There is a very high chance that your problem was already a someone else's problem at the past. Look for the problem in Stack Overflow and there might be an answer. However, if you do this as the your first, you will miss making strategies and brainstorming to overcome your issue. Always and always, try to make a solution by yourself. It will improve your decision making and solutioning a lot better. But, as I said, if you are in a hurry, better to make this your priority.

Finally as always, you can ask from a senior or from a colleague for help if you get stuck on a code. But I suggest you to do everything you can do before asking help from someone else. There is no shame in getting stuck in a code. Everyone does. Make that a learning opportunity for yourself and move on. If you are a junior, getting stuck in a code might look like a part of life of a developer. And, YES IT IS.

Good luck and unstuck yourself.

This article was published as the #week2 article for #4articles4weeks.

I did not know what to do. I was so broken inside. I was not a bright student back then. Only thing I knew was computers. I did not know programming. But what I did know was to play games and do power point. Then it struck to me. 'Why not a something related to IT?'. So, I looked for private universities which had IT degrees and found one with a Software Engineering degree. I had nothing to show for, except a failed result sheet. So, I had to do a foundation course and finally I was able to start my journey as a Software Engineering student. Three years later, I graduated.

Landing on my first software engineering job

I thought the graduation was the hard part. But, I could not be more wrong. The hardest part was to find my first job as a Software Engineer. I did not know how to make a CV first, so I googled and found a CV template and updated it. Then I sent to some companies and one company called me for an interview. A week later I went for the interview and guess what? IT WAS A DISASTER. I could not answer many questions they asked for. And I knew they would not hire me as for the job. So, I took a step back and googled again about the interviews. I had to make sure I pass the next interview.

So, to the topic. What should you really do before you land on your first job?

Prepare your weapons.

Guns? Nope! The knowledge. First take your time to identify yourself. Who you truly need to become. Then work on that. Read articles, questions, blog posts that related to your desired field.

I made the schoolboy error of casting a wide net at the start of my job search, believing that "they should hire me". But, no matter where you end up, you'll be spending the majority of your time at your job. What's the point if you can't get excited about going to work, or, nastier, absolutely hate it? Make a list of priorities that you are looking for. What kind of job that you seek to join. My priorities were simple.

• I needed a good work life balance.
• Opportunities and tech stacks where I can grow myself as an engineer.
• Challenging problems and ways to solve them.
• Good management.

Make sure you have something to show for. Usually at your first job, you will not have any prior experiences with projects. Is that true? Nope! You can build your own projects for your imaginative company, tackle the problems with your own solutions. They consider those as prior experiences with projects. Create a GitHub profile. Learn Git. And push your every bit of code to the profile, so the interviewers can see what you have been doing.

Build your network.

Find people who do the same work as you. If you are trying to land on a software engineering job, try to build your network around that. See what they usually post. Engage with their posts. Like them, comment on them. Make your self stand out on those posts.

How and where can you build your network?

LinkedIn

For every job seeker and professional, LinkedIn should be on top. LinkedIn is a community full of professionals in many areas such as technology, cookery, transportation, management and many more.

It is less spam-infested unlike many, the profile allows you to adaptively display all of your expertise, and, most notably, it has powerful and inexpensive connectivity features.

It's simple to expand your network on LinkedIn, but it involves more than just having to add every person you can consider of as a connection. The threshold for the quality of the relationship needed to request a referral is minimal, but not so minimal that you can simply be linked — you must have engaged in a (positive) conversation. This does not say that the interaction cannot begin or continue entirely on LinkedIn. So, who should you contact and how should you begin the conversation?

Visit the job portal and look for a few positions that inspire you. Look for companies that have former or current coders with whom you share something in common. You could have graduated from the same degree program or training course, or you could both have a solid desire to transform the world. Whatever it is, if they have previously hired people like you, they are likely to do so again.

You must also be prepared to discuss the strengths and flaws of your project with an interviewer. Many of my interviewers pulled up my GitHub page and started asking me to walk them through my code. I definitely bobbled the first time this occurred because I hadn't looked at the code in months at least! Preparation is crucial.

School Alumni

There is a high chance that people who were with you looking for the same jobs as you do. Eventually, they might get hired as well. Most companies hire people through referrals from insiders and if you can build your network with them, luckily they might be able to refer you for their company.

Also, your alumni group can be your support group where you can look for help whenever you face problems regarding coding and as well as your personal life. Humans more tend to success with their peers rather than going alone. Also, you can get ideas about interviews and how they have faced them in order to join the company. Connections can only be bad, if you made them with wrong people.

Next thing is events. From there you can find people like you as well as new opportunities if you join the correct event.

When you go to an event, talk to people, ask questions, and begin making contacts. If that's not your style, you can jot down the names and emails of people you find interesting and connect with them later on a not so public method.

Twitter

This can be controversial to some people. But if you follow correct people you will be able to get more knowledge about many things. I am a Software Engineer related to PHP, so mostly I do is follow people or companies related to PHP in twitter. Whenever they have updates about their technologies, first thing they do is posting a tweet in twitter. So, you will be able to keep your self updated about technologies more often than ever.

There can be many more ways to make connections. I have mentioned only the main things that I have done to land on my first job. If you found other interesting methods you can connect with people and make connections, feel free to add them in comment section so others can also follow them.

Do not use the same resume for every company

One mistake that rookies do is, making a resume in a general way, where they can send to multiple companies. You should not be doing that. Every resume needs to be altered and catered to perfection. And it should be according to the company you are looking for. Read the job description well and identify the keywords that they ask for. Add them into your resume in a creative way. Most companies do not read your resume's at first. They go through a system that selects most matching resumes. If your resume contains the keywords they are looking for, there is a high chance that your resume will have a spotlight on their system and jump through the first hurdle.

Most importantly, create your resume as per the job role you are looking for. As an example, if you are looking for a job as a Junior or an intern software engineer, they will not look for your photoshop skills. So, do not make your resume as flashy as possible. Your resume should be simple and should have everything about your projects, experiences and so on. It is a different story if you are applying for a designers job. In that case, your resume should show what you are capable of. So, a little flashy resume will not hurt you.

Cover letter plays a big role in hiring and has a huge advantage to yourself. They never call you before they see your resume. And your cover letter is the place to market yourself to your interviewer or the hiring manager. Make an attractive cover letter (the content should be attractive, not the letter itself) and try your best to sell your self to your hiring manager.

Your salary is the monthly subscription fee that the company pays you for your services. So, sell your self creatively.

Do not mess the interview, lying is not an option and failing is not failing.

Your ultimate goal is to attend to the interview and get selected, so once you get selected to an interview, try your best not to mess it up. Most of the times interviews consists of three parts.

1. General interview or the get to know interview
2. Technical interview
3. HR interview

Your target is to pass all these interviews. Not just one. Be prepared with your self. NEVER GO TO AN INTERVIEW UNPREPARED.

YouTube has content about creative answers for the majority of the interview questions. Isn't that like practicing the questions? Yes! If you have to. One word can mess your interview completely. So practice with yourself before you jump in on an interview. Do I need to memorize the answers? Again YES! You have to. Because negotiation is an art, selling yourself is an art. You cannot master an art without practicing it.

So, is it okay to lie in an interview? NEVER! That is one thing you should not do in an interview. Even though you lie in an interview, you will be in a big trouble when you get the job. You will be dragging yourself to floor as well as the others. So, NEVER LIE IN AN INTERVIEW. Be honest! Memorize the mastering techniques about selling yourself, not about lying.

Even though you completed an interview without any issue, there could be a better person than you. In that case, you will get rejected and you might need to send your resume to another company. But keep this in your mind. Failing is not failing. If I did not mess up my first interview, I would not know these things. Make your failures into learning opportunities. Hit hard on the next interview. If you fail that again, learn again. And hit much harder on your following interview. Never ever give up. Edison had one thousand failures before finding the light bulb. If he had given up, just think how dark the world would be today.

So, these are things I have done to land my first job as a Software Engineer. After the first unsuccessful attempt, it had taken me around a month to make all these things. But trust me, it is worth it. After that, I have never failed an interview yet.

If you haven't failed an interview yet and you are looking for your first job, do these things. It will never fail you. If you have multiple unsuccessful attempts, do not worry. Next attempt will be a success if you follow these. Trust me. I have mentioned these from my own experience. If it worked for me, it must be for you.

Good luck!

This article was published as the #week1 article for #4articles4weeks.

Now, for the second letter in SOLID. It stands for Open/ Closed Principle.

What is open closed principle?

The principle says "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification". That is nice! But what does it really mean?

The general idea about this is, you should be able to add new functionality to entities (classes, modules, functions, etc.) without changing it's existing codebase.

Let's discuss it with a real world example. Imagine you have a system with a notification system.

class Application {
    private $notificationType = null;

    public function __construct($type) {
        $this->notificationType = $type;
    }

    public function sendNotification() {
        $notification = new Notification;
        if ($this->notificationType == 'text') {
            // do work related to structuring the notification.
            $notification->sendTextNotification();
        } else {
            // do work related to structuring the notification.
            $notification->sendEmailNotification();
        }
    }
}

class Notification {
    /*
     * Send text notifications.
     */
    public function sendTextNotification() {
    }

    /*
     * Send email notifications.
     */
    public function sendEmailNotification() {
    }
}

Right now, you do not have any problem and this does not break the OCP (Open/ Closed Principle). But the problem occurs when you get another notification type that needs to be added.

class Application {
    private $notificationType = null;

    public function __construct($type) {
        $this->notificationType = $type;
    }

    public function sendNotification() {
        $notification = new Notification;
        if ($this->notificationType == 'text') {
            // do work related to structuring the notification.
            $notification->sendTextNotification();
        } else if ($this->notificationType == 'toast') {
            // do work related to structuring the notification.
            $this->sendToastNotification();
        } else {
            // do work related to structuring the notification.
            $notification->sendEmailNotification();
        }
    }
}

class Notification {
    /*
     * Send text notifications.
     */
    public function sendTextNotification() {
    }

    /*
     * Send email notifications.
     */
    public function sendEmailNotification() {
    }

    /*
     * Send toast notifications.
     */
    public function sendToastNotification() {
    }
}

Even though this seemed fine, this breaks OCP. Why? You have modified the existing class. By doing this, your development might break an existing functionality. This is not good.

So, how do we add functionalities to a class without breaking OCP? How do you extend the functionalities of a class without modifying it. Seems impossible? Let's discuss.

First things first, why do we need to extend without modifying a class? Let's say you are doing a complex code. If you are modifying an already working production sent code, you have to be 100% certain it does not break the existing functionality. I know there can be unit tests which you can test before deploying the new code. But there is a chance we should not take lightly.

So, how do we do this? Let's move step by step.

For this, you can use a design pattern called Factory Design Pattern (My next article will be about the Factory Pattern. Subscribe to my newsletter. So, you'll be notified once I publish it).

To resolve this issue, we are creating a separate factory class where we hold the notification details. If we have any more notification types in future, we can easily update the factory class without updating the existing Application class.

First, create an interface for the notifications. You'll get to know soon why we need the interface.

interface NotificationInterface {
    public function send();
}

Now create separate classes for each notification type and implement the interface on the classes.

class TextNotification implements NotificationInterface {

    public function send() {
        // TODO: Implement send() method.
    }
}

class ToastNotification implements NotificationInterface {

    public function send() {
        // TODO: Implement send() method.
    }
}

class EmailNotification implements NotificationInterface {

    public function send() {
        // TODO: Implement send() method.
    }
}

By implementing the interface, you also need to override the send() abstract function of the interface inside concrete notification classes.

Next stop is the factory class.

class NotificationFactory {

    /*
     * Select the notification type.
     */
    public function selectNotification($notificationType) {
        if ($notificationType == 'text') {
            return new TextNotification;
        } else if ($notificationType == 'toast') {
            return new ToastNotification;
        } else {
            return new EmailNotification;
        }
    }
}

When you pass the correct argument into the selectNotification($notificationType) function, it will return the notification class accordingly. Whenever we need to add more notification types, we can do so without needing to change the existing code. All we have to do now is initialize the notification type from our NotificationFactory class and create a new notification class by implementing our NotificationInterface . That is all.

Finally, you can simply call the function inside the factory class with the appropriate parameters from the application class.

class Application {
    private $notificationType = null;

    public function __construct($type) {
        $this->notificationType = $type;
    }

    public function sendNotification() {
        $notificationFactory = new NotificationFactory();
        $notification = $notificationFactory->selectNotification($this->notificationType);
        $notification->send();
    }
}

To summarize, the Open/ Closed principle is very simple to apply; it aids in the addition of new features by extending existing code rather than modifying it. To follow the Open Closed principle correctly, all you have to care about is whether you will modify your code in the future to add new features or functionality.

The reason we add the interface is, mainly you can generalize the send() function in concrete classes. So, you do not need to worry about the class you need to call from the base application class.

It is not over yet!

Advantages of Open/ Closed Principle

• Code is easily maintainable The fundamental advantage of this principle is that an interface adds another degree of abstraction, allowing for loose coupling. An interface's implementations are independent of one another and do not need to interact any code.

• Code is more flexible In the case of plugins, there is a basic or core module that may be supplemented with additional features and capabilities via a common gateway interface. Web browser extensions are a nice illustration of this.

That is about it for the day. Let's meet with the next article on SOLID Principles. That is Liskov Substitution Principle.

Complete list of SOLID principles that I have explained in this series.

Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Cheerio!