This section is sort-of a surreal diary where I log some thoughts about the phases of developing my Master's Thesis project in a romanticized, anecdotal and literary manner. Enjoy and do not take the following text too seriously. :)
The beginning
"Alright, let's do this.", that's what I thought. A system which will "keep track of time", it will know what buttons you pressed and it will do the same for you afterwards. It will replay your actions in front of you, and you will be able to see what went wrong with whatever it is you were doing. Sounds exciting, right? Maybe also a bit creepy for the more "Orwellian" ones (including myself..?). But there is no need to bring in the politics so soon, after all it's just an academic project, just my Master's Thesis. I finally got to this, after what seems to be an eternity of studying, working, and trying to find balance for everything else. And all I can think is: "let's get this done and get over with it".
But, where to start? I mean, I do want to get over with this but I still want to work for it, deliver something solid out of my efforts. And I certainly do not want to let my supervisor down, to whom I look up so much that, sometimes, I think whether I am just unworthy of collaborating with him on such a project. And with such things in mind, before I even began to answer that very first question, much more complicated (and, at the time, fairly pointless) questions started arising. How would it work? How would it be used? How would it be installed? Is it acceptable to have a user do this or that to use this system? Will the time I have be enough? How am I going to manage this when I have an almost full-time job at the same time? Chaos. The mind becomes blocked, incapable of comprehending anything related to the project anymore. Just, blank.
I was lucky enough to arrange that the second reader for my Thesis is a pretty technical person, and a very nice guy as well. So I went to see him, and discuss with him about some specifics of my project, hoping that he would help me solve all this technical madness I had inside my head. I explained him what my picture is with regards to how this system should work and what I figured that the scope was, and he would then point out risks, questions I should consider answering and several approaches for defining the scope of my project. Ultimately, he had a few valuable pieces of advice for me:
- try to think of the simplest case possible and work towards that first
- try to make it as generic as you can
- regardless of the implementation success, it is important that you explain in your report why you made the design decisions that you will make
So I decided to break it down and look at the building blocks of the system, the absolutely basic notions, the ingredients that would just make it work, for one simple case. And from there, we can see how it goes. After all, one needs to walk one step at a time in order to climb the mountain, and that's the way it is. Maybe this sounds obvious, but I had to repeatedly remind it to myself in order to realize it and make this chaos go away from my head.
Pencil & paper
After I managed to let go of this first wave of crippling stress, I started asking basic questions. "What is an event?", that was the first question I had to answer, since my system will be an event logger. I started sketching out the event object, thinking about what properties it would have and what meta-properties would be useful to create for tracking it, saving it and bringing it back to be (re)played. And the most vital of event properties is of course its type, which indicates what sort of action triggered a specific event, and for my system it would mean the opposite (what sort of action will this event trigger). I knew that the system should to work with Web-based applications, so I had to define a starting pool of event types that would exist in this context.
The notion which popped up right after defining the event was the one where I have two events, one happening after the other. I decided to loosely name that one "timeline", basically a string of subsequent events. Immediately, the need of determining the temporal relationships between events became obvious. Thus, a new property was added to the event object: a relative timestamp which indicates how much time has passed between the occurrence of the previous event and the current one.
Alright, so I had the "soul" of my project in place, its basic conceptual building blocks. It was time to start building the "skeleton", and this meant that I had to pick up my pencil and draw some lines & boxes. Data flows, communication schemes, some naive architecture which demonstrates a hypothetical trip of events & timelines from one end to the other. A host application, one back-end server, maybe two back-end servers... I had to put my thoughts into practice. I needed a proof-of-concept to see if what I was sketching out was moving towards a good direction.