Author: DeanBlackborough

Posted on

Returning to Costs to Expect, finally!

My own projects have taken a back seat whilst I’ve been busy working on a freelance project which scaled well beyond the initial scope, that project is almost over and I suspect I’m going to be free for a little while to work on my own projects again. I can start pushing towards the soft release of the Costs to Expect API and App.

The API

The API has been feature ready for a while, its issues are unnecessary complexity. When I started adding new “item-types” I opted for a little too much abstraction. I’ve been designing the budgeting system (on paper) for a while, it is not going to work in the same way as the existing “item-types” so I’ve been busy removing all the abstractions and in general refactoring the shit out of the API.

I didn’t look at the API code for a year, that time gave me a fresh perspective, I’m simplifying the majority of the “item-type” code, there is no need for everything to extend from a base class if there is going to very little overlap in functionality.

In addition to the refactoring I’m moving our tests local, rather than relying on a Postman collection I’m moving all the tests to PHPUnit. I can replicate every test in the Postman collection locally as well as test things that could never be caught by only looking at responses. I expect I will keep the Postman collection around because there are tests that a simpler to do with it but having everything local is going to be a major benefit and of course necessary for the official release.

I have 11 stories left in my tracker, the API will then hit our soft release milestone. This milestone has been a long time coming, I still can’t quite believe we are this close.

The App

The App needs more work, there are 24 stores in my tracker, my wife and I are yet to pick the App apart, so, more stories will get added. App development tasks are simpler, the API does the heavy lifting, the majority of the work on the App is presentation.

The App is closed source, the API is open source, we handle each slightly differently, with the App we are focused on the features and not so much the overall design, assuming it works, with the API, the design takes a front seat as it has to potentially be maintainable by more than just us. The reality is, I develop everything so I’m not really switching styles, we just might approach the backlog in a different way.

Official release

Once the App and API both hit their soft release milestones, I’ll cry, no really, this has been such a long time coming, I’ve been planning the budgeting and forecasting system, forever.

There might be a slight detour whilst I develop another App rather than get on with the Budgeting and Forecasting. As mad as that sounds given how long it has taken to get here, it can be thought of as an experiment/proof of concept. The budgeting and forecasting will not behave as per anything else in the App so I need to test the API and my front-end skills.

The next four months are going to be full-on, all we can do is see where we are in September and go from there.

Posted on

Jobs and tasks gamble paid off

I have spent the last 12 months developing a product for one of my long-term clients, I’m going to refer to the product as EWAQO for the rest of this post.

I initially thought EWAQO would be three to four months of work, lockdowns, homeschooling, the pandemic in general and feature creep put paid to that.

EWAQO is far from the largest product I’ve worked on, I’ve been a professional developer for over twenty years and have worked at scale, it is however the largest product I’ve created single-handled. The Costs to Expect API, Website and App are big when combined, EWAQO is in a world of its own, it has so many different systems and is immense.

I decided early on to go deep with queues and scheduled tasks, I wanted to keep the App fast for the user and do as much of the heavy lifting as possible behind the scenes. Typically, I’m using queues for complex user-initiated tasks/actions and scheduled tasks are for processing.

It is easy to handle the complex stuff behind the scenes, but there is a problem, you need some visibility. Before I wrote the first job I created the interface, that way the client can see what is happening, is a job running? Did it fail? What was the output? Who initiated it? etc.

This was the masterstroke and made so much of the complexity possible, the client could see what is happening, job classes and tasks are simpler to create because you don’t need to worry about the front-end, it all came together brilliantly.

I’m not done with EWAQO, as of writing, there are 27 jobs and 26 scheduled tasks and I have visibility of each one, I can see when they are running, what is due, when and why they fail, it all just works.

We are working toward the soft-release of Costs to Expect this year, part of that is developing two smallish apps that act as companions. Both apps will borrow heavily from what I learned developing EWAQO.