Why I’m Rebuilding EvolvePHP: Lessons From a Framework I Built Years Ago

 

Back in early 2016, while working on several PHP projects, I didn’t realize I was building a framework.

At the time, I had already learned CodeIgniter and was proficient with WordPress and Joomla. Most of the applications I was working on were not simple websites; they were larger business and enterprise systems with recurring requirements such as user management, authentication, roles, access control, sessions, administrative interfaces, and other shared functionality.

As I moved from one project to another, I started noticing a pattern.

I was repeatedly rebuilding many of the same features.

User management.

Login and authentication.

ACL.

Roles and permissions.

Database access.

Routing.

Sessions.

Controllers.

Common utilities.

I wanted a better way to reuse those capabilities without copying an old application and removing everything I didn't need.

 

The idea started with modularity

CodeIgniter influenced how I thought about MVC and application structure, but Joomla had also exposed me to a different idea that I found very interesting: components and modular functionality.

I liked the idea of being able to build a feature independently and then plug it into another application when needed.

Instead of every new project starting like this:

New project
    ↓
Build authentication again
    ↓
Build roles again
    ↓
Build ACL again
    ↓
Build common infrastructure again

I wanted something closer to:

Application
    ├── Users
    ├── Authentication
    ├── ACL
    ├── Reporting
    └── Other reusable components

If another application needed one of those capabilities, I could reuse or adapt the component rather than starting from scratch.

So I began creating my own structure around the applications I was developing.

At that point, I wasn't really thinking:

"I am going to create a PHP framework."

I was simply trying to solve a problem I kept encountering in my daily development work.

Then I realized I had built a framework

After deploying one of the applications, I looked at the underlying code more carefully.

By then, I had already created many of the things we normally associate with a framework:

• Routing

• MVC structure

• Session management

• Database abstractions

• Controllers and models

• Reusable components

• Configuration management

• Authentication-related utilities

• ACL and permission handling

• Common application helpers

The application-specific code was sitting on top of a reusable foundation.

At that point it became obvious that what I had created was no longer just a collection of helper files.

It was the beginning of a framework.

That framework eventually became EvolvePHP.

EvolvePHP grew with the applications I built

I continued using the framework for other projects.

Whenever I encountered something missing, I added it.

Whenever I found myself repeating code between projects, I looked for a way to make that functionality reusable.

Whenever an application exposed a weakness in the framework, I improved the framework.

So EvolvePHP grew organically.

It wasn't designed in one sitting from a perfect architectural specification.

It evolved alongside real applications and real business requirements.

That experience was incredibly valuable.

Several applications I built with EvolvePHP are still running today, years after they were originally deployed.

For me, that matters more than whether the framework ever became widely adopted publicly.

It proved that the ideas behind it were useful enough to support real systems.

What EvolvePHP 1 taught me

Building EvolvePHP taught me far more than I expected when I started.

It forced me to understand PHP beyond simply using existing frameworks.

I had to think about questions such as:

• How should requests enter an application?

• How should routes be resolved?

• How should controllers be instantiated?

• How should reusable components communicate?

• How should authentication state be handled?

• How should permissions be represented?

• How should application configuration work?

• How should database access be structured?

• How much responsibility should a framework take from the application?

• Where should framework code end and business code begin?

It gave me practical experience with:

• PHP internals and application structure

• MVC architecture

• Reusable software design

• ACL and authorization systems

• Framework development

• System design

• Design patterns

• Component architecture

• Application lifecycle concerns

Some of the architectural decisions I made back then are decisions I would not make today.

But that is part of the value of the project.

You learn a lot when you have to live with your own architectural decisions for several years.

Why I am preserving EvolvePHP 1

When I decided to begin EvolvePHP 2, one question was whether I should simply transform the existing codebase into the new framework.

I decided against that.

EvolvePHP 1 represents a particular period in my development career and a particular era of PHP development.

There is value in preserving that history.

It shows where the project started.

It also gives me a reference point when designing EvolvePHP 2.

There may be ideas worth revisiting.

There may also be decisions that serve as useful reminders of what not to repeat.

And practically, preserving the existing version costs me very little.

So EvolvePHP 1 remains preserved rather than being overwritten by EvolvePHP 2.

Why EvolvePHP 2 is a redesign instead of an upgrade

A lot has changed since I last worked seriously on EvolvePHP 1.

PHP has changed significantly.

The ecosystem has changed.

The way applications are deployed has changed.

My own understanding of software architecture has changed.

EvolvePHP 1 was designed in an era where a typical PHP application was largely expected to handle one request, produce a response, and terminate.

Modern applications increasingly operate around:

• Containers

• Cloud infrastructure

• Persistent workers

• Queues

• Background jobs

• APIs

• Distributed systems

• Observability

• OpenTelemetry

• CI/CD

• Horizontal scaling

• Docker

• Kubernetes

• Long-running PHP runtimes

Trying to force all of that into the original EvolvePHP architecture would create more problems than it solves.

Some of the dependencies are outdated.

Some design decisions belong to an older PHP ecosystem.

And EvolvePHP 1 is much more comfortable around the PHP 7 generation than the environment I want EvolvePHP 2 to target.

So EvolvePHP 2 is not:

EvolvePHP 1
    +
new features

It is closer to:

Lessons from EvolvePHP 1
        +
14+ years of engineering experience
        +
modern PHP
        +
modern infrastructure
        +
new architectural principles
        ↓
EvolvePHP 2

That distinction is important.

The problem I want EvolvePHP 2 to solve

Another thing that has become clearer to me over the years is how difficult software modernization can be.

There are many PHP applications still running important businesses today.

Some were built with older frameworks.

Some are custom applications.

Some are based on versions of PHP that companies would like to move away from.

But rewriting a large production system from scratch is often unrealistic.

A company may have years of business logic inside an application.

Thousands of database records.

Integrations with other systems.

Customers actively using it.

Employees depending on it every day.

Telling that business:

"Rewrite everything."

is rarely useful advice.

That is one of the problems I want EvolvePHP 2 to explore more seriously.

What if a modern framework could help developers gradually improve an existing application?

Instead of:

Legacy System
      ↓
Complete Rewrite
      ↓
Modern System

the process could look more like:

Existing System
      │
      ├── Existing modules
      ├── Existing business logic
      │
      └── Evolve Bridge
              │
              ├── New capability
              ├── Modernized module
              └── New services

Modernization could happen incrementally.

One capability at a time.

Building for change

That thinking has started shaping the philosophy behind EvolvePHP 2.

The goal is not simply to build another framework with routing, controllers and dependency injection.

Those problems have already been solved extremely well by frameworks such as Laravel and Symfony.

The more interesting question is:

How do we design applications that are easier to change several years from now?

That means thinking about things such as:

• Modular application architecture

• Clear package boundaries

• Explicit dependency contracts

• Safe execution lifecycles

• Persistent-worker safety

• Plugin architecture

• Observability

• Incremental modernization

• Framework interoperability

• Service extraction

• Upgrade safety

A new application may start as one modular monolith.

Later, one module may need to scale independently.

An old application may gradually move functionality into modern modules.

A company may want to adopt modern PHP without immediately replacing everything that already works.

EvolvePHP 2 is being designed around those realities.

Doing it differently this time

There is another major difference between how I built the original framework and how I am approaching EvolvePHP 2.

EvolvePHP 1 grew mostly through implementation.

EvolvePHP 2 is starting with architecture.

Before implementing major framework features, I am defining the decisions that those features must follow.

That includes architecture RFCs covering areas such as:

• Framework vision and scope

• Package boundaries

• Versioning and compatibility

• Module and plugin lifecycle

• Execution scope and runtime reset

• Incremental modernization through Evolve Bridge

• Observability and OpenTelemetry

I am also applying a test-driven approach to the framework itself.

Instead of simply adding a feature because it appears to work, I want important framework behavior to have explicit tests and architectural rules around it.

The goal is to make accidental architectural drift harder.

Looking back before moving forward

EvolvePHP 1 was never perfect.

I wouldn't build it the same way today.

But I don't regret building it.

It taught me things that I probably would never have learned by only using other people's frameworks.

It forced me to understand what happens underneath the abstractions I normally depended on.

And most importantly, it gave me something real to learn from.

EvolvePHP 2 is therefore not an attempt to erase the original project.

It is the next step in its evolution.

The first version was built from the experience I had at the time.

The second version is being built from everything I have learned since.

And this time, the ambition is broader:

Build a PHP framework designed not only for creating applications, but for helping those applications evolve over time.

That is the journey I will be documenting as EvolvePHP 2 develops.

 

The Ultimate Laravel Setup for VS Code: Free Extensions to Rival PHPStorm

 

Hey everyone,

I want to put this out there for anyone looking for the ultimate Laravel setup in VS Code. These extensions enable you to experience a superb development integrated environment that can be compared to paid versions like PHPStorm.

 

If you're new to Laravel development or need a robust extension setup, these will give you the required effect. They're all free to use!

Here's the list:

• GitHub Copilot Chat - Microsoft
• Auto Close Tag - Jun Han
• Auto Complete Tag - Jun Han
• Better PHPUnit - Calebporizo
• Code Spell Checker - Street Side Software
• Container Tools - Microsoft
• Docker DX - Docker
• DotENV - Mikestead
• ESLint - Microsoft
• GitHub Copilot - GitHub
• Laravel - Laravel
• Laravel Artisan - Ryan Naddy
• Laravel Blade Formatter - Shuhei Hayashibara
• Laravel Blade Snippets - Winnie Lin
• Laravel Docs - Austen Cameron
• Laravel Intellisense - Mohamed Benhida
• Markdown Preview Enhanced - Yiyi Wang
• Markdownlint - David Anson
• PHP Intelephense - Intelephense
• PHP Namespace Resolver - Mehedi Hassan
• Prettier Code Formatter - Prettier
• Tailwind CSS Intellisense - Tailwind Labs
• Thunder Client - Thunder Client
• Vue - Vue

Let me know what you think and how it has helped you in the comments below!

#Laravel #VSCode #WebDevelopment #FreeTools

Creating a Modular Tic-Tac-Toe Game with TDD principle in Node.js

Building My Command-Line Tic-Tac-Toe Game

Hey everyone, welcome back to my blog!

If you’ve been following my posts, you know I love experimenting with new ideas and tools. This time, I decided to take on a fun challenge: building a command-line Tic-Tac-Toe game from scratch.

But before writing a single line of code, I had to think carefully about how to approach the project. I wanted the game to be robust, easy to maintain, and simple to extend with new features in the future.

---

Choosing the Right Approach

After a bit of research, I decided to go with the popular modular design approach. At first, I wasn’t even sure which programming language to use. So, I did what any developer would do—spent some time digging around on Google.

Eventually, I settled on Node.js because it’s well-suited for this kind of project. Plus, I decided the game would run exclusively on the command line—perfect for Linux users and advanced computer enthusiasts who appreciate terminal-based apps.

---

Using Test-Driven Development (TDD)

Once I had the language picked out, I set out to build the game using Test-Driven Development (TDD) principles.

I began by breaking down the project into phases:

1. List out features the game should support.
2. Write tests for each feature.
3. Make the code pass the tests one step at a time.

This approach kept the project organized and helped ensure everything worked as expected before moving on.

---

Check Out the Code

The full game code is available on my GitHub repository: josiahking/tic-tac-toe: A tic-tac-toe game

When you have the time, give it a try—and see if you can beat my AI opponent. I’ll warn you though: it’s pretty smart. You might need an IQ of 200+ to beat it consistently! 😄

If you have suggestions for improvement, I’d love to hear them. Even better, you can contribute to the project—maybe add multiplayer support over the network using real-time communication. Node.js would be perfect for that!

---

Wrapping Up

That’s all for this project!

I had a lot of fun building this game and learned quite a bit along the way. Hopefully, you enjoy playing it as much as I enjoyed creating it.

Until the next post, stay safe and keep coding! 🚀

My Code vs AI(Co-Pilot): I Spent About 75 Minutes Solving a Pyramid Problem on CodeSignal — Here's What I Learned

Today I went on CodeSignal looking for a fun coding challenge to sharpen my JavaScript skills. I came across an ASCII art problem that looked deceptively simple:

Can you generate a pyramid of asterisks with N rows?
Each level adds two more stars than the level above, centered with proper spacing.

Here's what it looks like for N = 5:

    *    
   ***   
  *****  
 ******* 
*********

And for N = 10? That’s what I set out to build.

⏳ Time Spent: 1 Hour 15 Minutes

I took this challenge seriously—no AI help. I wanted to test my problem-solving process.

Here’s my final code after 75 minutes:

const printChar = "*";

function buildPyramid(rows){
    var asteriskCount = rows * 2;
    var pyramid = [];
    var spaceCount = 0;
    for(i = 0; i < rows; i++){
        var asterisks = "";
        for(c = 0; c < (asteriskCount - 1); c++){
            asterisks += printChar;
        }
        pyramid.push(addSpace(asterisks, spaceCount));
        asteriskCount -= 2;
        spaceCount += 2;
    }
    
    return pyramid.reverse();
}

function addSpace(item, spaceCount){
    var before = "", after = "";
    const space = " ";
    for(i = 0; i < (spaceCount / 2); i++){
        before += space;
        after += space;
    }
    return before + item + after;
}

console.log(buildPyramid(10));

🤖 AI's Solution (Much Simpler)

Out of curiosity, I later asked Copilot/AI to solve it, and this was its version:

(Q)Can you write a program that generates this pyramid with a N value of 10 in JavaScript? 

function generatePyramid(N) {
  for (let i = 1; i <= N; i++) {
    const spaces = ' '.repeat(N - i);
    const stars = '*'.repeat(2 * i - 1);
    console.log(spaces + stars);
  }
}

generatePyramid(10);

💡 Takeaways

• Don't overthink simple problems: I went deep with logic and arrays, while the AI focused on core string operations.
• Learning happens in the process: Writing my own solution helped me practice nested loops, string manipulation, and thinking in reverse order.
• AI is a powerful reference, but it's also satisfying to struggle and arrive at your own solution.

If you’re learning JavaScript or just want to keep your brain sharp, try solving small visual problems like this. You’d be surprised how much you can learn from 10 rows of asterisks.

👨🏽‍💻 Have you solved something cool lately? Drop a link or comment below!

From Go Tour to Go by Example: My Real Journey Into Golang

Go Programming Update: From Go Tour to Go by Example

Hello again! How’s it going out there?

Here’s another update just for you.

✅ What’s Next After “A Tour of Go”?

After completing the Go Tour, I moved on to the next learning resource — Go by Example. It’s a practical, snippet-based guide that teaches Go through annotated code examples.

But before diving deep, I had to set up an IDE for actual development.

💻 Choosing an IDE: LiteIDE vs VSCode

There are many editors out there, but I narrowed it down to two major options:

• Go LiteIDE
• VS Code with Go extensions

I decided to start with Go LiteIDE to get a more native experience.

⚙️ Installing Go LiteIDE Wasn't So Easy

Installing LiteIDE wasn’t as straightforward as I expected. It took me several minutes and a few web searches to get it right.

I had to follow multiple setup steps, but eventually, it worked.
📌 Spoiler alert: I’ll be writing a separate post on how to install and set up LiteIDE for Go.

🧠 My Observations So Far

1. Go Strings Use Double Quotes Only

Unlike languages like JavaScript and Python, where both ' and " work, in Go, strings must be in double quotes (").
Single quotes (') are for runes, not strings.

2. if/else Syntax Must Be Properly Aligned

Go is strict about how you write if/else.
This will not work:

if 1 == 1 {
    // do something
}
else {
    // error: unexpected else
}

This is the correct way:

if 1 == 1 {
    // do something
} else {
    // now it's valid
}

3. Still No Section About Comments or String Concatenation

So far, I haven’t seen an example of how to:

• Add comments
• Concatenate strings

This suggests that Go expects some prior programming experience from its users. It’s not hand-holding like beginner-friendly languages.

4. Arrays vs Slices in Go

Here’s a simple example to show the difference:

array := [3]string{"j", "d", "d"}     // Array
slice := []string{"j", "d", "d"}      // Slice

An array has a fixed size specified inside the square brackets.
A slice doesn’t specify the size and is more flexible.
They look similar but behave differently.

🧵 Final Thoughts (For Today)

Go continues to be an outstanding language — clean, powerful, and strict.
It forces you to think like a low-level systems developer, even while giving you modern conveniences.

I’m still getting used to the syntax and structure, but every day I learn something new that surprises me.

Until the next update — keep learning, and stay curious. 👋🏽

Learning Go: My Honest Thoughts After Completing the Go Tour in 2 Days

Go Programming Update: Day 2 – The Weird, the Wonderful, and the “Why Though?”

Hello again, and thank you for taking a moment to read through.

I understand your time is valuable, so I’ll keep this brief going forward.

🧠 Yesterday Was... Interesting.

Yesterday was another opportunity to experience something brilliantly human: a programming language created by man — Go.

Now, here are a few things I’ve learned that made me pause and go, “Wait, what?”

"In Go, it's common to write methods that gracefully handle being called with a nil receiver."

But… look at this code:

package main

import "fmt"

type I interface {
    M()
}

type T struct {
    S string
}

func (t *T) M() {
    if t == nil {
        fmt.Println("<nil>")
        return
    }
    fmt.Println(t.S)
}

func main() {
    var i I

    var t *T
    t.S = ""
    i = t
    describe(i)
    i.M()

    i = &T{"hello"}
    describe(i)
    i.M()
}

func describe(i I) {
    fmt.Printf("(%v, %T)\n", i, i)
}

Output:

panic: runtime error: invalid memory address or nil pointer dereference

There's nothing “graceful” about that! 😅

But honestly, if I had seen this code a week ago, I could only understand maybe 30% of it. Go code feels more like advanced programming—almost in the league of low-level languages.

🧱 Constructors and NewSomething

Then I stumbled on this: image.NewRGBA.

That threw me off completely at first. Coming from PHP or JavaScript, I assumed New was part of the method name.

Turns out, New is a convention, not a keyword. The actual type is image.RGBA. Go uses NewTypeName() to return an initialized instance — like a constructor function.

🟰 nil Instead of null

Go doesn’t use null — it uses nil.

🚫 The Underscore _ Is Not Just a Placeholder

for _, v := range arr {
    // Do something with v only
}

_, ok := someFunc()

The underscore isn’t decorative — it literally means: “Ignore this.”

💡 Keep an Open Mind

If this is your first time learning Go, please… don’t get your hopes too high in the first few days.

You're going to say “Hmm, this is weird” more than once.

• No shorthand if statements — braces {} are required.
• No class keyword — methods are tied to types via receivers.
• No inheritance — Go favors composition.
• Go forces unused imports and variables to be removed — and that's a good thing.

🧬 Go Method Syntax

func (receiver Type) MethodName(arg ArgType) ReturnType {
    // ...
}

If you don’t have a receiver, it's just a function. With a receiver, it becomes a method.

🔠 Naming Conventions

Go uses PascalCase like this: ErrNegativeSqrt.

I’m used to camelCase and snake_case, so this is another learning curve.

🧠 Old Habits Die Hard

I still find myself:

• Using () in if statements
• Ending lines with ;
• Trying to destructure like it’s JavaScript 😅

But that’s okay — it’s part of the learning curve.

🎉 I Completed the Tour of Go!

In just 2 days, I finished the official Go Tour tutorials! 🎉

I’m proud of this progress. It’s a strong start, and I’m beginning to appreciate the beauty and simplicity Go aims for — even if it’s not always obvious at first.

💙 Onward and Deeper

Next, I’ll dive into more advanced Go concepts: goroutines, channels, error handling, map, struct, slice and possibly building an API.

Until my next update, stay safe and stay healthy.

Learning Go Programming as a Web Developer: My First Impressions and 4-Week Plan

So I Started Learning Go

I recently began learning the Go programming language after putting it off for years, considering it unimportant on my to-do list.

My First Look: A Tour of Go

Go is a simple and clean programming language that experienced web developers can pick up fairly quickly.

My goal is to learn Go in under 4 weeks with an aggressive approach.

As developers, many of us get bored when we spend too long learning a new language. We often abandon it and move on to something more exciting. That’s exactly why I’ve set a strict deadline—to stay focused and committed.

The Go syntax reminds me of TypeScript, Python, and maybe even Java—they share some similarities.

Go doesn't care about semicolons (;), and I see now why it's better suited for developers with some programming experience.

Go may not be the best choice for absolute beginners. It has a few advanced concepts that take time to grasp. But honestly, with discipline and determination, anyone can learn it.

One thing I find impressive is how Go handles imports. You can import packages that aren’t even on your server—pretty neat!

Oh yes, if you've used Java before, you’ll recognize the use of main. In Go, everything starts with:

package main

import "fmt"

func main() {
    fmt.Println("Hello, world!")
}

The way Go defines variables is also cool. You can use the var keyword, or a shorthand := for quick declarations.

Constants are declared using the const keyword, and you can define typed or untyped constants.

Go also has something called slices, which are like advanced arrays. To be honest, I initially found them a bit confusing. Why not just improve arrays? Why introduce slices? Maybe it’s just the tutorial that didn’t explain it well.

One thing I do appreciate is how Go handles loops. It's clean—no unnecessary complications. Just a simple for loop. I wish arrays were that straightforward too.

Unlike other languages like PHP, JavaScript, Node.js, Java, Kotlin, or TypeScript, Go keeps looping simple. There’s no for-in, foreach, while, do-while, or any of that mess. Just for. 😁

Final Thoughts

So far, Go isn’t as fast as I expected—but maybe I haven’t dug deep enough yet. I’m still exploring and plan to share more updates soon.

Stay tuned...

Simplest way to remove and uninstall react-native module or package

Hi guys, I recently ran into an issue while working with react-native. I installed a package for storage but the package didn't work as I had expected and it was causing significant error in the mobile app. I had to install a different package.
So, i went ahead to remove the previous package by doing normal npm uninstall --save
The above code only had effect in my package.json file, and caused the app to start showing white blank screen.
After several hours battling with the app and codes, I discovered that decided to try using react-native command rather than npm.
Show I did react-native uninstall which worked and everything began to work in the app again. The effect of this code is that it not only uninstall the packages the right way, it also unlinks them if they are linked.

Thank you for read, happy coding.


Follow me on twitter: http://www.twitter.com/_josiah_king Join me on Google+: https://www.plus.google.com/u/0/113541005774136102412/posts/p/pub?cfem=1

My Portfilio Prior to this Day

Hello, below you can find some of my most inspiring and complex projects i have worked on:

Payvalue.ng

Ereg.nepcservices.com.ng

Nibsaconference.org

Amlsnconference.org

Moodle.africaglobalexportmarket.com

Africaglobalexportmarket.com

Scholarshipdraw.com

Fortereg.com

Demeterexports.com

Bruudaarchitects.com

 NDE Smartfarmer Project (offline)

And lots more which are still offline.

Follow me on twitter: http://www.twitter.com/_josiah_king Join me on Google+: https://www.plus.google.com/u/0/113541005774136102412/posts/p/pub?cfem=1

Jquery Circular Countdown-up Wordpress Plugin

Follow me on twitter: http://www.twitter.com/_josiah_king Join me on Google+: https://www.plus.google.com/u/0/113541005774136102412/posts/p/pub?cfem=1