The amount of actual code I managed to spit out today for the time I had set aside for Devember is not a whole lot, although I did get some changes in place.

For the most part, day 3 has been taken up with various research elements. In particular, the tooling I’m using, and benchmarking.

I’ve been making good use of the issue tracker in my repository (I should probably link that more often) to track what I’m planning to do, which is something that I’m not really in the habit of doing. At my day job, the system we use to track ongoing tasks is, to put it bluntly, dumb as a sack of hammers.

JetBrains tools have integration with a few different issue trackers, one of which happens to be gitlab. Since part of my Devember is evaluating gitlab to see if I want to install my own local copy, I thought I would investigate this integration.

I won’t bore with the details too much, but to suffice it to say that the way that WebStorm (in this case) uses task tracking is not really compatible with how I’m used to working on issues, so a lot of this experimentation went nowhere.

On the face of it, I can see how it would be handy if I didn’t work the way that I do; the IDE saves the layout of editing panes on a task by task basis, so switching between tasks allows you to maintain optimal layout. However, I tend to always use the same layout, which makes this more of a pain to use because the default is to start a task with no files open unless you press magic keys.

There were some other oddities that seemed to impede my workflow more than they actually helped, but what really got to me was how I had about 5 issues in the issue tracker and the tool displayed each one of them about a dozen times, making the list hugely crowded. I’m not sure if that’s a failing of the IDE (and my configuration thereof) or a consequence of how gitlab works, or what.

In any event, except for some code cleanup that I did during those investigations, the rest of my time was spent researching and benchmarking.

In JavaScript, you can use Object.defineProperty to configure properties on object. In particular, you can provide accessor functions for getting and setting the value, which allows you to expose values in a way that is read only or read/write (or write only, but that seems less useful). This seems like a great way to expose property values in my own classes to ensure that nothing can alter values in an untoward way, but I was curious if there was a speed benefit.

I eventually used jsperf.com for this task when my google-fu proved fruitless, which took me a bit of a time. For one thing I spent a while chasing down errors that it turns out seem to be in the boilerplate code of the page and nothing to do with my benchmarks per se. I also accidentally set up the tests to include the defineProperty call as part of the loop, which makes the operation seem mind bogglingly slow. Here’s a tip: you don’t want to be calling that function often if speed is of the essence.

In the end I determined that there is no real speed difference at all (which is what I sort of suspected, but did not want to bank on), so I can proceed with my plans of data isolation tomorrow. Of course, this still makes me a little sad because it means that name conflicts between the accessor functions I create and the underlying values means that something somewhere has to be named in an unappealing way. We’ll see what tomorrow brings.