now though the list of items provided in that post are indeed implemented I am still working on it today , finalizing the streamline and integration stage of the work. Often during the course of an implementation , you'll find areas from previous code that maybe weren't as efficient as you thought and you change them, or you find other areas that would work better when integrated with the newer code for the current implementation. However, most of the time after implementation is spent weeding bugs out of the system and making sure the implementation actually works. It is one thing to write compilable code , another to make sure it does what you wanted it to. In many ways this part of the process is like sculpting with your eyes closed, you are able to get a rough outline of the final synthesis from the implemented items but you still need to smooth the edges and discontinuities into an efficient whole.
Many of the tasks specified in the list, were independent from many others but all were required to achieve the desired outcome of a working guest messaging system. The gotcha's come into play afterward, for example I mentioned in this post, that I needed to add a new method to retrieve all the guest request rows from the participant_queue table, since then I've also needed to add bits of code to various areas in the UI that govern building and managing the guest session as unique from user sessions that perform messaging. The integrative approach I am taking is a bit more difficult to manage but it is faster to implement, plus once it is working I can later optimize execution by extracting the portions unique to guest messaging into dedicated templates and thus more efficiently model an efficient scalability and memory use curve under high load of guest message requests and transactions. This process of weaving the loose ends together reminds me of the process of large scale civil construction that has led to the creation of some massive public works projects throughout the world.
The "Chunnel" (channel tunnel) between England and France employed the use of TBM's (see image) , tunnel boring machines..these massive devices are essentially mechanical worms, that dig with diamond carbide tipped faces into bedrock while lining the walls with smooth concrete liners as they go. They have increased the efficiency of tunnel boring for the construction of train and road tunnels tremendously. Their use in the channel required that two teams with at least two TBM devices were deployed at the British and French ends of the tunnel respectively, these were then guided through the use of GPS beacons and lasers as they drilled their way under the channel's rock. An amazing feat of engineering that spanned the channels entire undersea length of over 22.55 miles, in the end this seemingly blind act of trusting GPS and lasers ensured that when the two drilling teams met under the English channel the tunnels were aligned to such precision that they were off center by only 358mm(14.1inch) horizontally and 58mm(2.3inch) vertically.
The close agreement between the ends resulted from the consistent process of implement and test performed along the way. Survey,Dig, probe, Dig, Survey, Dig, probe ...etc. It may seem that this task was next to impossible but by conquering one small possible problem at a time the final tunnel was connected and went into service over 10 years ago. The process of refining an implementation of code tasks to agree with a final design goal and troubleshooting is like the work that the tunnel creators had to do in aligning the tracks despite the small center line error difference between the two ends. Ultimately the fact the tunnels were misaligned by so small a degree amounted to no problem for rail layout since the difference was within the tunnels design parameters. In engineering, "perfect" is a relative term ..so long as all desired problem conditions are accounted for in a solution. ;)
Channel Tunnel Wikipedia page:
Channel Tunnel PDF guide: