Event Horizon - yet another calendar app
I started to work on a calendar website sometime in January this year. As I was just beginning to work full-time again, the development process was slow to begin with. But the seemingly simple concept presented more and more challanges, and as the project got a bit more complex and complicated (most probably due to bad design decisions and lack of experience), I started to encounter some arcane behaviour and weird bugs. I didn’t care, because I enjoyed looking for the root causes and eliminating them. But then I started to get tired. These days, I do actual work on it a few hours each week at most, and I have an immense list of missing features, bugs and, most importantly, technical debt entries in a todo.txt file. I started it with a “do it wrong then fix it” attitude (a la Scott Adams), which is not a sustainable approach in software, it seems. It’s not impossible that I will be able to weed out the stuff, if I allocate a fixed interval for it from time to time. A big motivation for not abandonning it is that I am using it as my only calendar and event planner.
But I do think that besides the obvious red flags it possesses, I actually learn a lot while I am making this. I look back at some part of it that I wrote a month ago and cringe while trying to correct it. I learned some HTML, tons of CSS, some Python and MongoDB, and heaps of Flask, Javascript and HTTP in general.
I also learned how important it is to make a project open to extension, modular and non-repetitive - because few of those are true to this one. I now understand why code reuse is not just a buzzword. Because my head hurts when I think that I have basically copy-pasted two very similar classes in Python… which are still in the code. Go find them.
It’s not RESTful, it’s not responsive, it’s not accessible. I’ll try my best to correct them. Promise.
