The Time Keeper app

Open sourcing a time tracking desktop application

Photo of Salvador Molina Moreno
Tue, 2016-11-08 13:52By salva

One of the great things of working at Code Enigma is the labs time we get every year. During one or two weeks (sometimes we split this time), we get to work on something of our own choice: we've worked on a range of things that go from Symfony bundles to show a summary of support time usage by our clients, to crazy Raspberry Pi gadgets, passing by some Drupal-based modules to provide a real-time poker planning utility for teams to estimate project tasks.

Usually, when my labs arrive I have plenty of things I'd like to work on, specially in a time when it feels like every month a new language is coming out. However, this year it hasn't been difficult for me to choose a technology or language to play with: JavaScript.

I can read, understand, and write JavaScript code, no problem. I've written some reasonably complex JavaScript apps (e.g: the poker planning tool mentioned above), but the fact is that I've never taken the time to learn JavaScript properly, understand its multiple features and concepts (closures, anyone? Heard about the module pattern?). I was merely able to throw out JavaScript lines mixed with jQuery code. Instead, I was just throwing knowledge from other programming languages, in the form of JavaScript syntax for the browser to execute. Was I writing JavaScript? I doubt it. That's not uncommon, and the result is not surprising: code that does what you expect it to do (in some cases, at least), that you think you understand, but you really don't, and, inevitably... yes, you got it:

baby covered in spaghetti

Praise for those who have never written spaghetti code

So, this time I wanted to build an application in vanilla JavaScript, with the sole purpose of going through the "pain" of it, properly understand and make use of some of its main features and concepts and, overall, become a better JavaScript developer. The other big reason why I wanted to write something in JavaScript, was that I was quite excited about the rising of frameworks like NW.js and Github's Electron, which make it incredibly easy to write cross-platform applications in JavaScript. If you think this is crazy, you might be surprised after looking at the list of apps made with Electron.

The Time Keeper application

So for this occasion, I decided to build a time tracking desktop application, based on NW.js. It seemed like a goal complex enough to go through the things I wanted to learn: proper usage of JavaScript objects and prototypes, module pattern, closures, elements being introduced in ES6, and usage of some of the more modern DOM APIs (namely client-side storage techniques, in this case). The result? You can see it in the picture below (and yes, it's inspired by the desktop version of Toggl):

time keeper app screenshot

For the theoretical part of the learning, I decided go through the You Don't Know JS series, by Kyle Simpson, which I found incredibly enlightening. I didn't manage to go through all the books, just the first two, but all I can say is they're full of good examples, and really, really, really in-depth coverage of why things in JavaScript work the way they do. If you want a good learning resource for JavaScript, YDKJS is a safe bet. 

The aim of this blog post was to share with the community the results of the time spent working on labs. While the application is not fully packaged to be distributed "as is", any developer will be able to run it locally, just having NW.js installed, and following the standard instructions to run any NW.js app. You can find it in github: https://github.com/salvamomo/time-keeper.

Time Keeper  application screenshot

I plan to do some more work on the app: some small fixes, UX improvements, adding a preferences section, keyboard shortcuts support, and support for more metadata for time entries (eg: project information), as well as generating actual binaries that can be simply downloaded and installed without having any NW.js knowledge, so if you're interested in it, head over to the issue list in github!

Unfortunately, some things were done in a rush, and I spotted things that were clearly badly done, after I had written them, or started to be inconvenient as the application grew to incorporate more features. That's good, it is (almost) my first application written in Vanilla JavaScript, and it has allowed me to spot good things, bad things, good patterns, bad patterns, etc. There are a lot of TODOs in code, but hey, it's mostly a learning and testing playground, so that's the point, isn't it? It's still Spaghetti code, as patterns were not applied consistently (I would use a given pattern or technique to implement one thing, and another one for a different thing, for the sake of actually dealing with their differences, pros and cons, scenarios of use, etc). So, don't take the app itself as a good example for any of your JavaScript learning!

I'd say all the points in the previous paragraph are a sign that this year's labs were worth the time. Despite all the inconveniences and struggles of writing a JavaScript app without any solid examples to look at or without external feedback, I now have a more solid foundation of JavaScript, and I'm much more confident about my JavaScript knowledge, feeling pumped and ready to take on my next AngularJS project... eurrgh.