So ages ago, I decided that I would embark rewriting the Sugar Labs activity library (or ASLO, named after the web address). But this did not ever get to the stage where it replaced the original ASLO. There are lots of reasons that this project never worked, many of them social:
I would also say I made many experimental (in reference to my experience, defiantly not experimental on the whole) technical decisions. Some of them seemed to turn out well; for example, separating the backend and the front end helped ensure reliability despite a very unreliable backend. However there were many which were not too great. Mainly, I suffered from stack overflow; as in there were too many unknown technologies that I used to build it. Probably the nail in the coffin of this project was refactoring it to use a message queue. First, I used fedmsg (why not, Fedora uses it and they are cool), which I did not invest enough time to understand. I then migrated to Apache Kafka (because if one thing is complex, use a different complex thing), which yet again was more complex than my needs, leading to lots and lots of issues.
Also the GitHub integration was comical. I must a been under a wave of fanboy at the time. I believed that storing the activity metadata versioned in git was a good idea, even when every activity commit caused a metadata change. Thank god I never got this deployed into production.
So I made some mistakes. But I would totally give it another shot! How would ASLO2v2 look like?
I hope you enjoyed this article. Contact me if you have any thoughts or questions.
© 2015—2023 Sam Parkinson