In both our products and projects we collaborate on, one of my main concerns is bridging the gap between technology and user needs. I believe that is critical to focus on functionality while pursuing technical excellence.
As an example, let me tell you how we use concepts as compilers and stack machines to simplify the management of our products by our clients.
At Divisa iT we have a great experience in developing form automatization systems as, for example in our platform Proxia® Suite. However, and as I like to insist to my clients, these systems cannot work always on their own, and you need to tune them to obtain desired result. So the question was, could we do something else for the user?
As is often the case, the answer came from comparative analysis. If a kid succeeds at Scratch, what will be able to do a motivated adult? Although Scratch cannot be used directly, the idea is a perfect fit. Obviously we were not going to develop something from scratch - since time-to-market would be unprofitable-, so I decided to use Google’s Blockly, since this tool provided us with the perfect basis to develop our solution.
The problem arrives when you need to interpret this result. Please, take into account that our needs included not only controlling approbation flow, but also allowing calls to the client backoffice. In order to solve this challenge, the best approach was interpreting this code from server side. Reasons for this decission involve security ones, flow control and last, but not least, we were looking for a device indepedent solution, meaning that it could work on Web, Swift and Android.
There are endless solutions as, for example, creating a complex grammar using ANTLR (I have used this approach several times successfuly), but I really think that approach is actually overkill for this problem. If you are wondering about basic – but really basic – elements that are part of programming activity, the answer will be : code, compile and interpret.
Therefore, we just need to modify Blockly to ensure that compilation produced neither a high-level language, nor an specific DSL but a pseudo-assembler which could be interpreted in an ad-hoc stack machine. Something as shown in next figure.
Think in this pseudo-assembler as a series of instructions that are going to be interpreted by a virtual machine, this machine is a software based one, and we were going to develop it. Those instructions include, e.g., store this variable, compare result with zero, if result is true jump to instruction 35, etc. Please, notice, that we are not only including steps, but also storing state in memory. Memory is, in this case, actually like a stack that follows a LIFO algorithm.
The usage of this stack machine, makes easier not only to interpret code at server side, but it also helps us to ensure a number of critical requisites as being fault-tolerant and allowing us to create those approval flows. As you know, an approval flow consists of :
Since we were not going to allow a process to run endlessly – in an active or passive listening -, solution involved persiting full program state, that means stack and the information about process execution – execution line -. So combining: stack machine, finite state machine and a physical data persistence. Problem solved !
Icons created by FlatIcon