Category: Development

Posted on

Budget Pro development begins again

The budget overview screen in Budget. Shows the this month and the two following months and the expenses for each

There was an initial flurry of development on Budget Pro in October/November and then it stalled. The stall was primarily down to lack of time as I started a freelance project in the November and needed to obviously dedicate time to that. However, whenever a free evening popped up, I chose not to work on Budget Pro and instead work on Budget or the freelance project to try and finish it sooner.

No sinister reason behind this and we still fully expect to release Budget Pro within the first half of 2023. The issue was simply that there were still things to learn from Budget, our free budgeting App.

Budget Open Beta

During the open beta, we learnt far more than we expected. We had to improve the demo, we needed to rework the Budget overview and there were several small features which we deemed necessary and didn’t finish adding until the end of the year.

In late November, I decided to delay any further development on Budget Pro until the official release of Budget; that way we would get to see and resolve all our problems in one codebase and not worry about having to rework anything in Budget Pro.

We always planned on there being two offerings of our budgeting tool – Budget, the free version and Budget Pro, our subscription option. In building Budget first, it has enabled us to identify and iron out potential issues before developing the much more complex version.

Our two Apps, Budget and Budget Pro solve the same problem, but they tackle it slightly differently. Budget is aimed at everyone; Budget Pro is aimed at users who need to collaborate or have much more complex budgets requirements.

Budget Pro is due out within the first half of 2023 and as soon as we are able, we will open it up for beta, the plan being we don’t make any of the same mistakes we did with the launch of Budget.

Posted on

It is always caching!

five keyboard keys on a black surface spelling out the work cache

In October I added multiple account deletion options to the Costs to Expect API – you can delete your data for a specific App, reset your data for one of our Apps or delete your account entirely.

There could be a large amount of data to delete so I decided to handle the deletes behind the scenes with jobs. This worked well and during all my testing, there was never an issue. If an issue does occur a notification gets sent and I can fix the issue.

However, after release, I tested with a throwaway account, and it wasn’t working. As a user I could reset my state but when I signed in again all my data was still showing.

For a little while I was perplexed. The API wasn’t erroring, the data was being removed but Budget still showed the old state. The first hint happened when I tried to do something in Budget; I immediately got an error from the API, a budget item couldn’t be created because the resource didn’t exist.

Aha! I knew what the problem was. I said to myself, “Budget has data, the API doesn’t, there must be a cache issue somewhere.”

Budget doesn’t retain a cache so it can only be the API. I rush (really, I did) to my IDE and low and behold, my jobs don’t clear the cache after deleting the requested data – oops!

How did this happen?

Well, that’s easy. During development, I turn off the cache on my local instance of the API as I don’t want the cache getting in the way of any new features I’m writing or debugging. I test before I make a new release, manually and automatically. Though clearly, I’m not always turning cache back on.

The Solution

The solution is easy – do a better job of testing but it isn’t quite as simple as that. I’m going to update my automatic tests to include testing with and without caching enabled. More importantly though, I’m going to expose the API cache status.

It isn’t unusual for the development or staging version of your Apps to highlight their status – a bar at the top, a different background, a visual notifier of some kind. I’m going to update Budget and all the other Costs to Expect Apps to include this notifier and show the state of the API, is caching enabled? Is it in debug mode? That way when I’m testing a data state feature, I’m more likely to spot that status and think about the extra steps.