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.
The story goes that one day in the winter of 1928, Joe Kennedy stopped
to have his shoes shined and when the boy finished, he offered him a
stock tip: “Buy Hindenburg”. Kennedy sold off his stocks right after
after concluding: “You know that it is a time to sell when shoeshine
boys give you stock tips. This bull market is over”. This was just
before the Great Depression.
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.
The Command and Query Responsibility Segregation (CQRS) Pattern is a solution to the problems that are inherent to the Create, Read, Update and Delete (CRUD) approach to data handling. We use Haskell to explore the problem scope and the proposed solution described by the pattern.