#projectphpnomad — Public Fediverse posts

Rethinking Developer Life and Productivity with Rapid AI Advancements

https://openchannels.fm/rethinking-developer-life-and-productivity-with-rapid-ai-advancements/

I’m experimenting with integrating PHPNomad with NativePHP today. The thought of being able to run the same models and PHPNomad libraries in my desktop apps, and the server for that same app is just too dang useful to ignore! So many possibilities!

I’m already using this right now for an MCP server I’m running internally at Novatorius, and if this shapes up nicely, maybe I can cut back considerably on the amount of TypeScript I have dedicated to type coercion in the desktop app.

The number of microservices I’ve spun up this year using PHPNomad is something to behold.

I’ve really gotten into a groove with that system, and it’s just so, SO nice to have every single thing I build and manage using the exact same framework. It’s better to be consistent than great, and my biggest bottleneck right now is reviewing code. I can review and identify code smells so much faster with PHPNomad because I know just from a glance when something isn’t built using the patterns it should be built using.

Plus the CLI I buit for it scaffolds most of the code when we’re building greenfield projects, and that saves a ton of tokens when building.

I love it.

PHPnomad just got a CLI, and giving AI access to it has reduced my token usage CONSIDERABLY. Some actions are reduced by a factor of nearly 70!

Better Async Support in WordPress With PHPNomad + Action Scheduler

https://github.com/phpnomad/wordpress-integration/releases/tag/3.0.0

The Trough of Despair

Besides, it’s really healthy to journal more-regularly. I’m already doing that in a private context, but I think it would be good to also share some of those moments on my blog. That’s the spirit of this damn thing, after all..

So, here’s to new habits. Or is it just old habits made new again. Or maybe it’s the habits we made along the way. Either way, let’s get caught up on the goings on for the past several months. Hopefully future updates won’t be so…broad, and I can hone-in on specific aspects a little closer moving forward.

The last personal update I published was in last December, and I talked a lot about re-acquainting with being a visionary in my business instead of the developer employee, and honestly that’s been the overall theme of this entire year. Over the last 6 months, Novatorius has committed thousands of lines of code for various clients, as well as updates to Siren.

Most of that code’s been written by others. What I write these days is mostly to make life easier for the team. Usually PHPNomad libraries.

But other than that, almost everything in my life lately has been all about leadership, team dynamics, organization and processes. There’s been a lot of professional growth for me in that regard, with Novatorius peaking out earlier this year during a busy time with about 15 people reporting to me, or reporting to someone on my team. Which, for me, that’s about 3 times the number of people I’ve ever managed on projects before, and it was a lot. So, since then, I’ve been focusing on leveling myself up to become better at communicating and leading people.

Unsurprisingly enough, that focus has paid off in dividends in areas I didn’t even realize needed improvement.

1. I’ve become much better at talking with friends, family, and my children.
2. I’ve found that my clients are generally happier, and I’m not over-promising.
3. I’ve learned to generally speak less. (lol that sounds so bad but stay with me)

Most of this has come from learning to listen, and leveraging better questions to prompt people to think for themselves, and allow me to either guide them to the best answer, or to gather more information before I suggest a solution.

I’ve been saying that I am becoming an actual problem solver instead of a solution creator. This has been one of the biggest changes for me, because my entire career I’ve been looked at as “the person with the answers”. It comes with the territory of being an engineer your entire adult life – you just assume that you’re the one who has to have an answer to every problem. That’s a hard habit to break.

Perhaps the most surprising thing is how much of these skills have allowed me to become a better coach for my children. I always thought I was pretty good at this, but I’ve been able to drastically improve this, and have been able to do better at asking more non-leading questions that get answers from my kids. For example, I’ve been able to much more-reliably meal prep during the week because I’ve stopped asking “what do you want to eat for dinner” and instead asking things like “what did you enjoy last week?” and “look at this cookbook and pick 5 things that look good for next week”.

The unfortunate consequence of all of this learning is that I utterly failed this Summer at forecasting my finances and my sales, and the result is that I have been dead ass broke for the last couple of months. I’m honestly in a respectably-sized hole right now, and I don’t love that.

I’m diggin’ my way out, and I have a pretty good-sized shovel, but needless to say I’m going to be doing a much better job of keeping my eyes on my sales process in the future because asking your parents for a loan so you can pay your bills is just not something anyone wants to do.

I don’t feel shame in this, necessarily, but it was a real wakeup call. I’m still a very small, fragile, business full of a few big rocks, and if any of them leave my jar I’m going to be hurting in a big way. Fortunately, I have the things in place to improve that, and have a path moving forward to ensure that we do better next year.

The simple reality is Summer is always slow in the agency world, and I need to expect that next year. The most-painful part is that we have absolutely made enough this year for me to not be in this position – I just didn’t forecast well-enough to realize that I needed to slow my roll.

So that’s where things stand now.

My biggest focus at the moment is playing the balancing act between balancing the demands of my high-touch clients that pays me now, with investing in processes and systems in my business to allow me to carve out some more time to work on the future growth of the business. It’s a ludicrously delicate balance, and the target moves from month-to-month, but the opportunity to make the transition is one of the biggest reasons why I left my job to work for myself in the first place, so I’m going to keep doing it in the meantime.

Overall this year has been a constant roller-coaster. Some days, I’m having nightmares that my kids won’t have anything under their Christmas tree. Other days I’m fulfilled, excited for the future, and jumping headlong into this journey. I’m mostly concerned about my mental health and maintaining my levels of burnout, which thankfully I have a few great systems in place to maintain that because otherwise I’d be totally fucked.

I’d be lying if I didn’t say this put a pretty big toll on my stress levels. It’s been a lot, and I wouldn’t exactly say I’ve been okay all the time. One of my dear friends, Chris Badgett of LifterLMS mentioned to me in a recent phone call that I’m in what he calls “The trough of despair” and I’ll tell ya what, it’s a pretty good articulation.

But in-spite of all of that, I’m still optimistic about where I am, where the business is heading, and where the coming months will take me. I’ve managed to assemble a small, focused team of people who are helping me grow the business, and fulfill the promises we make. We’re not exactly putting a dent in the earth right now, but we have dreams, a vision, and every week we’re rowing in the same direction more often than last week. That momentum is why we survived this past summer at all, and I believe that upward trajectory will continue in coming months.

Until then though, I’ll be celebrating the small wins with homemade cake.

I Released a 2.0.0 of PHPNomad Tasks

https://github.com/phpnomad/tasks/releases/tag/2.0.0

PHPNomad As A Static Site Generator

Wait a minute…why can’t PHPNomad make PHPNomad’s documentation site?

At Novatorius, our projects increasingly venture beyond WordPress. I recently shared how PHPNomad can function as an MVC framework with some configuration.

I’ve mentioned it a few times on this blog that once I started using PHPNomad, I realized that I want to use it for everything. WordPress plugins, apps, services…why not a static site, too?

After evaluating my initial Docusaurus setup, I realized this was entirely feasible. I just needed to implement a few key components that my MVC framework setup didn’t have yet:

1. Support for routing from directory structures
2. Markdown compilation
3. A local server setup
4. A command to compile static files

With these features in place, PHPNomad was ready to power its own documentation site.

There’s a few things that I particularly love about how this is set up.

1. It does not need Node, or Webpack.
2. The dependency stack is minimal compared to other setups. If you have PHP and Composer installed, you have what you need.
3. It’s dead-simple to set up with GitHub pages
4. Customizing the non-markdown content can use whatever template engine you want, including vanilla PHP if you want. I like Twig, so I used the Twig integration for this.

Now, that doesn’t mean you can’t use Webpack if you need some robust JavaScript or whatever, but for a basic documentation site? Is that really necessary? I don’t think so Instead, I opted to leverage Pico CSS with minor custom styling tweaks. The only JavaScript file is for syntax highlighting via Prism.

The actual script that compiles everything just uses PHPNomad, and is literally just calling a PHP script.The local server is just using PHP’s built-in webserver feature.

Real World Benefits

It’s wild to think about static site generation through the nomadic lens. We’re not just talking about another static site generator here – we’re talking about using the same exact patterns we use for everything else to build documentation.

Think about that for a second. Most documentation solutions are like “Hey, learn our special way of doing things!” But with this approach? If you know PHPNomad, you already know how to build and maintain the docs. The same strategies, the same templating, the same everything – just pointed at markdown files instead of database records.

The best part? I didn’t have to compromise on anything I love about modern documentation sites. I still get the clean URLs, the nice navigation, the markdown processing – all of it. But instead of learning someone else’s system, I’m using the same patterns I use everywhere else. That’s exactly what the nomadic approach is all about.

This means that anyone on my team at Novatorius has a pretty good baseline on how to maintain this repository. So, if there’s a problem, or something needs done to maintain it, I have a much wider range of people who can help. It’s not this awkward codebase that is totally different from what I build in every day, it’s using the same patterns I’m using everywhere else.

It’s a perfect example of what gets me so excited about PHPNomad. Once you have these patterns down, you can just… use them. For anything. Dynamic sites? Check. WordPress integration? Done. Static documentation? Why not! It’s all just PHP doing what PHP does best – getting stuff done.

Looking Forward

I’ve made the repository public, and I’m considering turning a version of it into a GitHub template, similar to the MVC app template.

The ability to develop in a consistent environment, regardless of the final deployment platform, continues to validate PHPNomad’s approach. As I’ve often said, once you get comfortable with PHPNomad, you want to use it everywhere. The consistency in patterns and methodology across different types of projects is invaluable.

Change Datastore Methods to Use Generators

The current datastore interface returns arrays for collection methods which leads to memory and performance issues in REST implementations where N+1 queries are sometimes unavoidable. By changing these methods to use generators, we can process items as they arrive and maintain constant memory usage regardless of collection size, creating a more efficient implementation without sacrificing usability.

https://github.com/phpnomad/datastore/issues/6

Restructuring Datastore Events in PHPNomad

We’re moving datastore events out of the database layer and into the datastore layer while also splitting operation traits into paired versions (with and without events) to give developers more control over event emission. This change breaks backward compatibility but creates a more flexible, truly nomadic system where developers can choose exactly which operations should emit events rather than being forced into a one-size-fits-all approach.

https://github.com/phpnomad/db/issues/7

Remove Concrete Container Solution and Create Integrations With DI Libraries

I have come to realize it’s likely time to pivot away from PHPNomad’s simple container system, and embrace integrating with existing solutions, instead.

https://github.com/phpnomad/di/issues/6

Feature Request: Make it possible to provide a class instance to binding transformers

https://github.com/phpnomad/event/issues/2

Archive The Mutator Package

https://github.com/phpnomad/mutator/issues/2

Pitch: Remove Core Package Completely

https://github.com/phpnomad/core/issues/8

Ripped off a bandaid today. Finally got around to properly tagging all PHPNomad packages, and setting all of them up in Packagist. Currently at 40 repositories, so I needed to get ahead of this before it got out of hand.

Proposed New Facade Pattern That Supports Multiple Containers

https://github.com/phpnomad/facade/issues/2

PHPNomad As An MVC Framework

I needed a way to make Siren run outside of WordPress. After careful consideration, I decided the best route to take was to set up the last couple of packages needed to just make PHPNomad capable of running as its own MVC framework. I spent a weekend creating the strategies that WordPress handles for Siren using various Symfony packages and other dependencies. After that, I structured it so that the app runs PHPNomad, registers the routes embedded in the application properly, and allows you to create views specific to the app if-needed.

Then promptly after proving the concept, I set it aside and went back to working on the million other things I have going on right now (the first few months of launching Novatorius has been a lot, y’all.)

Fast-forward to today, one of my devs that’s helping me with a client’s WordPress theme mentioned that he was using a little local setup to render Twig files without depending on WordPress. Our internal theme framework uses PHPNomad and Twig for rendering, so it’s easy-enough to transfer the twig architecture into WordPress as we go.

But as he was talking about it, I realized that I had already solved that problem with my MVC framework for Siren, I just needed to extract the last few bits to create a template that can be used in any context, not just Siren.

Fast forward a couple of hours, and bam, the initial version of PHPNomad’s MVC framework is ready to go!

It’s not documented, the packages still use git instead of composer, and it’s still really early in the process, but I’m really excited about it because I’ve been wanting to run PHPNomad’s documentation as a PHPNomad application for a while now, and I think this is the last piece I needed to be able to do that.

Some Real-World Benefits

What I love about this, is that it’s already starting to show how powerful the nomadic approach can be. Our first live use-case of the MVC framework was not to build a web app, but to help development for a WordPress theme. That’s wild when you think about it.

Imagine you’re building a WordPress plugin. Traditionally, you’d need a full WordPress installation, a properly configured theme, and all the associated overhead just to start development. Since we use the nomadic approach, we can:

• Develop and test your core functionality independently
• Write and debug your code in a clean, isolated environment
• Create strategies that the WordPress integration can implement later-on.

So now, if we start our development in the MVC framework, we can create controllers that use strategies for rendering and everything else, and simply set them up to return dummy values in the MVC app. The theme can then compile the what it needs from the app, and include strategy implementations specific to WordPress, and voila! it all works.

This is a first major step toward making the front-end just as nomadic as the back-end. Really exciting stuff!

Conclusion

I’ve said this before, and I’ll say it again – once I got comfortable with PHPNomad, I just want to use it everywhere. There’s something so great about never switching codebases. No matter what you write, it’s always using the same patterns established by PHPNomad.

From here, I’m really excited to think through how to set up a markdown-friendly rendering engine so I can set up some kind of Docusaurus-like documentation setup that runs using this framework. Right now I only have a PHPEngine and a Twig Engine, but I’m sure it would be simple-enough to set up a markdown engine, and handle automated routing. Right now the MVC framework uses a config file for routes, but that can be yanked out and custom logic can be used instead. For another day, perhaps.

Spent time writing docs for PHPNomad yesterday, and the fruits of that labor came through already, when I was able to link to the docs a few times to help a developer with a PR.

I always think about docs last, but then find myself wishing I had it months ago at the same time.

One of my favorite things about working with PHPNomad’s strategy-based…

One of my favorite things about working with PHPNomad’s strategy-based approach has been that if I want to use a different thing to implement that strategy (eg: Guzzle instead of wp_rest_*), ChatGPT can usually slap together a workable implementation of the interface quickly.

Then I just swap them out in the app, and everything just works.

I’ve successfully managed to put together a pretty darn good MVC framework with PHPNomad, with the help of a few platform-agnostic PHP libaries. I got Siren to run on it, too! Over a weekend I was able to make a WordPress plugin built with PHPNomad run on its own server, completely outside of WordPress. It went well enough that I bet most plugins that are built with PHPNomad it could run on a microservice that doesn’t depend on WordPress at all in a month or two.

Working on plugin deployment flows today in-between meetings. So grateful I abstracted all of this out in a way I can re-use it.

Maybe I should do that PHPNomad Laravel integration sooner than I thought. This is getting bad.