Month: September 2019

Yesterday was release day; I released v2.00.0 of the Costs to Expect API and pushed two minor updates to the Costs to Expect Website and Web app.

Other than two minor issues, the releases went better than I expected. I did release a small hotfix that fixes one of the problems as it was publically visible, the other will get resolved in v2.01.0.

I have two Postman monitors that run daily; I also run these regularly during development to try and ensure I don’t break anything. Collection one contains all the HTTP requests the Website makes; collection two is more thorough and has HTTP requests for nearly all API endpoints. The two collections include around 1200 tests, these test the HEADERS, returned status codes and the response body. There were no tests for the issues; they slipped through the net. I have added a ticket to my tracker to add tests to catch any possible regressions.

My Postman collections are far from perfect; they give me some confidence, but as is evident based on the v2.00.1 release, there are still gaps.

I’m going to work on improving the monitors, for the last six months, anytime a feature gets added to the API, a test gets added to the relevant collection. Testing is going to be especially important when I start developing the app in a few weeks.

The initial development work for v2.00.0 of the Costs to Expect API is almost complete. I’m just one dev session away from all 1200 Postman tests passing.

I used the word initial, the v2.00.0 branch works; however, the two core features are not going to be complete until a couple/few .01 releases after v2.00.0. The base v2 version is about getting the database ready and ensuring all the migrations are valid; it is a significant change to the v1 database.

Permitted users are pretty much complete, the API will be missing the management of users, but that will quickly appear in .01 release.

Multiple item types, this is the big one.

As mentioned above, the database work will be complete; I should be able to write simple migration files for all additional releases without affecting existing data. The code is a little bit of a clutz; I’m merely joining to the only known item type sub table.

Updating all queries with a join to the item_type_allocated_expense table works; however, the code isn’t dynamic. When additional item types get added, creating, deleting, sorting and searching will all fail.

Once I am happy with the initial v2.00.0 release, I will add permitted users management and then work out how I am going to refactor the code to support dynamic item types. I have several ideas; however, I need to come up with something scalable and going forward will work for what I have planned for v2, v3 and beyond.

I had planned the first (private) release of the Costs to Expect app to be in late September, given the additional work, I suspect it will now get bumped into October.

We should still have something ready for public consumption before the end of the year. We are experiencing a minor bump in the road; these issues aren’t anything I wasn’t going to have to work out anyway, I have to solve some interesting problems sooner rather than later.