The 78 solutions method

While I work well within an agile system, when it comes to doing a combination of consulting for other people, doing fractional CTO contracts and building my own software for release, I follow my own method: 78 solutions. The 78 solutions idea is really simple: I solve 1.5 problems every week. Each solution builds upon other solutions and I maintain a detailed map of what I have already built and tested. If you consistently solve 1.5 problems a week, you solve 78 problems a year, and if the solutions build off of each other, within a few years you can tackle major problems that would have required a whole team years before.

From a software development point of view, this involves building software in modules. You have to assume that each module will be used for other things ahead of time, so you make sure that each module can run fully independently of others, and take the time to properly test each module before you deploy. Once your module goes from theory to battle-hardened, take the time to comment the module, explain what you did, and explain how it can be adapted in the future. From there, I summarize the comments in a spreadsheet that I keep of everything I have.

Over the last five years, I have watched the early investment in solving 78 major problems a year start to pay off. Formimp is older than my daughter; it started off as a way to simply deliver contacts made via the contact form on my first Hugo website to a Slack channel so I could reduce the sheer amount of email I receive. Now Formimp powers the contact form in every Windows application I build.

A help concept that started off in the FitnessTracker/StorePhotos projects is now something I can just import directly into all my other software packages. It is very powerful, uses the private Formimp implementation to deliver support requests to a channel where we talk regularly, and has in-app technical support documents for every single page in the application. That support system is very easy to implement now. It's just a copy and paste and is built into the entire Siteimp project.

Introducing Siteimp Watch

And after all that... I'll get to the point. Like all my other applications, every single part of Siteimp is a module. Each module is designed to be used in other places and is built to be fully self-contained so it is not dependent upon any other modules that I build. Consequently, the monitoring feature built within Siteimp was fully self-contained.

As I worked more with Siteimp, I started finding little issues where its monitoring didn't quite do the trick. For example, I run a small local AI model and interact with it via a tablet while I cook. It's my recipe book and a way for me to remember how many times I have salted a dish, keep track of where I am in a new recipe, and find where I am in the process. It's by no means perfect, but it beats the hell out of getting raw meat juice on a cookbook. As the youngs say, IYKYK.

It's a great tool and I've learned a lot about deploying local models, including that holy crap, when a local model goes down it goes down in the most annoying way imaginable. It doesn't just report that it's dead... oh no, it sits and spins. Sometimes it sits and spins when I ask it a complicated question; other times it sits and spins because it's dead. I set it up as a Siteimp monitoring target and it was pretty good... but the one-minute scheduler tick, and the one-minute monitoring interval that it enforced, didn't quite give me enough fidelity.

And so, I knew I had to make some changes. But I've run a version of Siteimp for a long time, and so I know the market that this level of deep website integrity scanning will appeal to. And I know that it's a different market than would be drawn to being able to monitor local resources at extremely low intervals, such as a ping or fetch every second. So, I knew that I needed to make a small split.

And so, Siteimp Watch was born. Built off the exact same module that powers Siteimp's local monitoring feature , Siteimp Watch uses a more efficient scheduler. Since it doesn't have to load any of the expensive tools that Siteimp relies upon to collect all the data it collects, it is fully optimized for speed. Whereas Siteimp will turn monitoring off during scans because there is a lot going on, Siteimp Watch can run uninterrupted, by anything but cursed Windows Sleep, and keep track of everything that is visible to your local machine on your local network.

While Watch can augment cloud-based monitoring, it is not a replacement for it. If you want to be sure that your systems are up, you need a reliable uptime monitoring service. The truth is, if you want cloud reliability at home you're going to end up building a small-scale data centre and will have to run your own redundancy. Some people really enjoy doing that kind of work, but not everyone does. And if you don't seriously enjoy the work, you're better off from a cost point of view just using a cloud-based service. Watch can do things available in only the highest tiers of cloud-based uptime services, like monitor endpoints at one-second intervals. But it's not a full replacement.

We'll be releasing both Siteimp and Watch this summer. Watch will be sold at a lower price point because it's quite different and better serves a very narrow purpose.

About the Author

Greg Hluska is a performance-obsessed developer focused on improving Core Web Vitals and real-world speed. He built Siteimp to make optimization faster, easier, and more reliable. Learn more about performance on the Performance Optimization blog. Currently working primarily on the Fitness Tracker application and 78solutions, Greg is busy. But not too busy to spend his free time with his child.