Every application proposal trying to win the heart of a Fortune 500 company today not only needs to claim to be Agile—oh, sorry, SAFe—but also based on a microservices architecture. After high-profile microservices disasters like Dell’s, we understand that a myopic microservices approach may not end up well. What if we could have all the benefits of a microservices architecture but none of the drawbacks?
When I first started tinkering with Java in 1996, I was less than impressed at how sluggish the JVM was and how Java Applet-powered sites would be crippled by an annoying, CPU-hogging, grey rectangle. But, it was a miracle nevertheless. I was running Linux and Windows on x86, my job’s machine was a DEC Alpha (RISC) and some friends were Mac users (68k and PowerPC). Java ran in all of these platforms; so did Perl scripts, of course, but that’s another story.
Those who do not learn history are doomed to repeat it; the saying goes. Many organisations are still paying the price for vendor lock-in and struggling to get out of “enterprise” platforms such as WebLogic, WebSphere and TIBCO, as they desperately try to break down their monoliths and become cloud native.
There is nothing more frustrating than spending time dealing with expenses since it is an activity that adds zero value to our customers and contributes nothing to our personal development. In short, doing expenses is an utter waste of time. In this post I show how I automated my expenses using Expensify and Greasemonkey.
In this article we explore the Event Sourcing Pattern and its cousins (Retroactive Event, Parallel Models and Materialised View) using a Haskell model to investigate the implications of implementing said patterns and the challenges that arise from their use. In particular, we note that the Retroactive Pattern is difficult to implement in an efficient manner whenever the possibility of inserting an arbitrary number of “missed” events between existing events is desirable.