If you go back in time to earlier in February, my utility app, PHP Monitor had just reached 30 stars, this a year and a half after the first version was released on GitHub. One of the soft goals I set when I refactored the app a while ago was to reach 100 stars by the end of the year.
On the last day of March, PHP Monitor blew up on Twitter. At the time of writing this, the app has received 621 stars on GitHub. I’m very proud that so many folks seem to like what I’ve built.
Tweet goes boom!
So, what happened? On March 30th, I noticed a bunch of folks of the Statamic CMS dev team ended up starring my repository, and shared the app on Twitter, which led to bunch of folks starring the repo. Wow. I thought that was pretty cool. In one day, I went from 30 stars to 75 or so. I was pretty surprised, but hey, that’s how the internet works, right? People share stuff.
I was curious if this influx of stars would continue the next day. Boy, was I not aware of what was going to happen next…
The next day, on the 31st, things really escalated. Marcel Pociot’s tweet really blew up, who tweeted about the tool after briefly reaching out via Twitter DM. It was the primary source of traffic for the project on GitHub. It got retweeted a bunch so I assume a lot of people saw it.
Due to this tweet blowing up, I received an amazing amount of helpful feedback and compliments from the Laravel community in a way I did not expect. The fine folks at Laravel News also posted about my tool the next day, so that was dope to see as well.
I’ve always been aware of the fact that sometimes someone sharing your stuff can blow it up, but I was not ready for the amount of positive feedback I received. I figured that I’d blog about it now that stuff’s cooled down a bit.
Even the current maintainer of Valet, Matt Stauffer, reached out to ask me for my thoughts on the Laravel Valet API he’s been working on with Marcel, and it all has been a very positive experience.
I don’t put any analytics (or crash reporting) in my app, so I don’t really accurately know how many people are now using the app.
However, it turns out you can find out how many people installed your app via Homebrew, assuming they did not disable analytics.
Not counting direct downloads, PHP Monitor has been installed over 1500 times in the last 30 days! For someone who is a small, reasonably unimportant developer, those numbers are quite staggering.
You know the rules…
Now that I’m talking about the no-analytics rule, let’s talk about the fundamental “rules” I have in mind whenever I tweak PHP Monitor:
-
The app has to respect the user’s privacy. No personal information is transmitted to the internet and HTTP requests should be limited. Currently PHP Monitor does not send any HTTP requests.
-
The app needs to be native. Yes, it is easier to build an Electron app, but I like to program in Swift and most importantly, can tap into some low-level APIs if I write native code. So, PHP Monitor will not become an Electron app. This also means that I don’t have any plans for a Windows version. Sorry, folks.
-
The app should be light on your computer’s resources. A low memory footprint and low CPU usage are a must for a utility app such as this. I want you to not notice that it’s running. PHP Monitor cannot have any major overhead, in short. Thankfully, Xcode ships with a bunch of tools which allow me to keep the CPU usage, storage IO and memory usage low.
-
Limit the external dependencies. I try to limit which third-party code I pull into the project, preferring to code up my own alternatives that I can scope to the needs of the project and refactor where necessary. (Right now, I’ve got one external dependency for the upcoming v3.4, and I’m looking into removing that dependency and writing my own code.)
-
Limit feature requests. I’ve had requests about adding, for example, a “Start mysql service” menu item, but I won’t add that to the app since it’s not directly related to Valet or the PHP services.
Those are the fundamental rules that I keep in mind during development of the app. If I ever reject feature requests or issues, I mostly reject those on basis of one of these rules, or about practical concerns.
What’s coming next
Version 3.4
I figured it would be a waste not to mention what’s in the works for future versions of PHP Monitor. Version 3.4 will be coming later this month. I’ve addressed the following things:
- Global hotkey added: You can now go to Preferences and set up a global hotkey to trigger PHP Monitor.
- More hotkeys: Each item that triggers an action should now have a shortcut; extensions are limited to the first nine (extensions 10 and onwards don’t have a shortcut).
- Scan all .ini files: Often requested, and finally here. All your .ini files are now scanned for extensions.
-
Speed boost for PHP version switch: The
brewcommands that PHP Monitor runs in the background are now parallelized (where possible) so you should see a speed boost of a few seconds if you have multiple PHP versions installed. - Stop all services has been added, and will let you know via a notification when it is done.
- Restart all services will also let you know when the services are done restarting via an additional notification.
Version 4.0
You might be wondering — what are the plans for the next major update, if any? I’ve got the following features listed as things I’d like to add to the app:
- Watching config files so that PHP Monitor immediately notices changes
- Showing a list of parked and linked domains (w/ PHP version requirements)
- Showing compatibility for each site (determined via
composer.json) with the currently linked PHP version - A preference (turned off by default) that automatically restarts services after toggling an extension
For now, I’m taking a break after version 3.4, until the new API is available in Valet. I’ve also got a few big projects for my day job so I’m taking it easy for a bit with after-work stuff.
Thanks for all the kind words and support. If you’ve used the app for a while now and you really like it, please consider sponsoring, it really helps out.