Category: Laravel

Posted on

Supporting multiple measurement units

Chalk sketch of two puzzles with words ingress and egress

I’m working on a freelance project in which I need to support multiple measurement units. In the App customers can provide their required flow rate in litres per second, litres per minute, litres per hour, cubic meters per hour, gallons a minute or imperial gallons per minute.

Warning: This gets really complicated, fast!

Imperial and Metric

You might have noticed we need to support imperial and metric measurement units. Well, that means we need to support mm, meters, degrees Celsius and the relevant inferior imperial versions some people still use. You know who you are.

Ingress and Egress

To keep business code simple, I have ingress object. These ingress objects take all the given values and convert them to a ‘known’ unit of measurement for each type. I then process all my calculations and do not need to be concerned with converting anything whilst I’m calculating. Once everything is calculated I pass everything into the egress objects, these convert all the data to the original unit and format.

Customer data is sacred

I store everything in the given format. I’ve tended to find over that it is better to store the original customer data and convert behind the scenes. Customers do not like it when their entered values of three gets returned as the 2.99997 the next time it appears on the screen.

I’m only a little way into the project but so far this is working well. Having a single interface to deal with is making my business code much simpler. I only need to care about the units for a value at the start and the end.

Hopefully, all goes well, only time will tell.

This project is the gift that keeps on giving, here is another post on integrating with Business Central.

Blog posts on freelance projects are deliberately a little vague as I can’t really divulge too much, I can talk about general stuff but obviously I’m never going to mention specifics.

Posted on

Budget Pro is in development

I started playing around with Budget Pro at the end of October, initially the landing page and ideas for the design. I’m still very much in the preliminary stages but I don’t think development will take too long as I have the experience of Budget behind me.
Originally, my intent was to take a copy of the Budget code and build all the new features on top and although possible, I’ve realised that long term this just isn’t going to work too well.

Budget is capable but there are two core features which should really be accounted for up front and not tacked on to a working design. Adding support for sharing and multiple budgets means I need to create some sort of “Budget Manager” that knows who owns a Budget and what controls each user has. Additionally, I need a way of surfacing a summary from each Budget rather than just visually as per the free version of Budget.

I’m not going to throw away the Budget code and start again, that would be stupid. The tested Budget service code works well and will just need the odd tweak here and there, it is more about how the service is wrapped and returns data and lessons I’ve learned during the development of Budget.

Budget and Budget Pro are both going to be supported for the foreseeable future, but they are their own products. Budget will get new features and even borrow features from Budget Pro, but it will not become Budget Pro.