Naming Things is Hard 2

Josh Bruce
Feb 7 · 5 min read

Think it’s time to revisit something I wrote a little over a year ago and see the progress that has been made. With that said, this will be less generic and abstract and more practical application in real life. 8fold, and its platform, has been evolving a lot over the last year.

2018 organically turned into a cleaning house kind of year as practitioners began really considering where they were with 8fold and their part in it. 2019, it seems, is a resetting year. Which apparently includes our approach to software.

Of course, this brings up the interesting point made by “Uncle” Bob Martin who asserted that the architecture should not be hidden behind the implementation or framework. When we look at the root of our projects we should be able to glean something about the software being developed, not the environment in which the software is being built or run.

That quote is from the first article I wrote on this subject and I’m still working out just how to do that. I’m building,, and on the LAMP-stack (Linux, Apache, MySQL, and PHP). Further, I have Laravel on top of that stack. Finally, a base install of Laravel is pretty recognizable.

I can’t decouple entirely from it; however, I can change it up to make it visually unique to my world. Laravel has a concept called Service Providers. These Service Providers are like miniature applications. They can have their own routes files, their own views, and, most importantly, can live where you want them to; including above the Laravel install directory.

The server doesn’t care that we’re using Laravel, just that we’re pointing it to a directory with a file it can do something with.

Composer’s psr-4 flag can assign a namespace to an arbitrary directory. I learned this (or at least thought about it) last year in fact when I put the services providers I developed outside the installation I was using:

“psr-4”: {
 “App\\”: “app/”,
 “Eightfold\\UIKit\\”: “../../private-packages/laravel-uikit/src/”,
 “Eightfold\\Registered\\”: “../../private-packages/laravel-registered/src/”,

Of course, this isn’t limited to Laravel Service Providers. The UIKit reference up there is just a library like any other.

I’m in the midst of *severely* overhauling all the things ever. I’ll spare you the full list and limit this to *just* You can follow the saga on Twitter. You can definitely comment here as well (or on Twitter, you know, whichever).

Here’s what it looked when I started. It doesn’t tell a human story. It tells a technical story. Folders with names like config, public-packages, private-packages, and so on.

One of the things that frustrated with this was that we have three sites, (currently down, working on it),, and This setup required three Laravel installs. The domain is just the bridge from the land of the living to the land of Tron. The server only cares that we point it to a directory that has something it can do something with…doesn’t even care what it’s named. This will end up being a public directory inside Laravel.

There is benefit in that but I would like true try three domains with one install so I only have to upgrade Laravel once. I saw this article on the subject and might give it a try to basically make Laravel the host, for all intents and purposes. But, what’s really next after Laravel is something I call AMOS, which is short for Alexander MidKnight’s Operating System (long story).

AMOS is basically what I was building from 2005 to 2011. Laravel basically matches what I think AMOS might have turned into to, if I had continued. And, now I don’t have to.

AMOS, for this spin-off resurrection, is comprised of various core applications; kind of like openGL is a core application of macOS. The core apps are inspired by ancient Mediterranean deities. For example, Charon is the core application responsible for registration and authentication as he is the ferryman of the River Styx carrying the recently deceased to the land of the dead (or virtual). Further, Seshat, is the Egyptian Goddess of scribes responsibility for various post-handling operations (when this Medium post autosaves, it would go through Seshat).

Then, just like any other operating, applications can be installed on top of AMOS. Of course, from a technical perspective, they’re all just Service Providers; except AMOS for now, he’s just a directory.

Looking at root as a stranger to this, we can see a directory called /AMOS (look into that later). We can see there’s a directory called /AppIdeasmith; so, chances are dealing with software (if that wasn’t already obvious). Then there’s a folder called /Laravel, if I’m familiar then I should be able to infer that this some type of website leveraging the Laravel framework. /zzSites is currently holding the static sites 8fold scaled back to in January, 2019.

You may notice the /!docs folder at the top there. This folder contains various design drawings. The exclamation mark takes advantage of sorting used in pretty much every computer I’ve seen. Symbols have a rank just like every other character. Symbols are before numbers, which are before letters. This ensures that that docs (non-code) directories are not mixed in with the actual code directories; thereby making it easier to scan and parse.

When we expand the AMOS directory we see all the deities and helpers. `CoreAphrodite` mainly handles views and will mostly be the UIKit leveraging 8fold Component and Elements. CoreCharon, as I said, will mainly be registration and sign in. And so on.

When it comes to naming things, you might be asking why keep the the Core prefix? And that’s a fair point considering things I said in the first part of this. Having said that, I actually haven’t committed to having the invisibles here. I’m thinking of putting them in root. So, when I create more Apps, one will be able to easily distinguish AMOS, from the Core that he helps coordinate, and the Apps who leverage the others.

I’m hoping to eventually get to the point where the Laravel directory is somewhere I rarely go, if ever. Not because I don’t like Laravel but because I don’t like the extra cognitive load scanning required to find things in there. I usually grab a search engine, find a community post, and they tell you the path to that file you’re looking for.

So, there we go, taking it one step further from having the Framework dictate (or at least overly inform) the environment developers interact with.

Josh Bruce

Written by

Coach, philosopher, writer