In a recent project we felt it beneficial to introduce the Money pattern. There are many good resources on this pattern, so I will delegate to those for further definition. We decided that encapsulating this into a immutable value object allowed for a cleaner API and removed the fear of any unexpected mutation bugs. However, we noticed a spike in memory and processor usage when wishing to perform many successive actions on such values i.e. summation.
When a web application reaches a sufficiently large size, it can become infeasible to perform all actions required within a single web request/response life-cycle. You may find yourself wishing to for example - batch up and send queued emails at particular intervals, or process payments asynchronous to the point in-time the user made the initial request. In this post I would like to discuss our changing use of background processes (both time-dependent and continuous) due to increasing throughput demands.
An interesting problem arose last week when we wished to generate a listing of recently completed jobs (along with their shortlist fees). Upon review of some earlier attempts, we did not like the aesthetics present when many of a particular shortlist fee were clustered together (i.e. two or more adjacent jobs with the same shortlist fee). What we were instead looking for was to create a constraint-based ordering that when applied to the recently completed jobs, would give an even distribution of shortlist fees (data-set permitting).
Throughout the fix I found myself seeking a clear definition of what both
debouncing a function actually entailed; as it can be very easy to mix the two subtly different concepts.
An AVL tree is a self-balancing binary search tree, where-by the height of a node’s children differ by at most one. In the event that this property is violated a re-balancing process takes place.