Announcing programming projects & blog commitments

I have just added two new sections to the blog: a Programming Projects page and a Blog Commitments page. Check out those pages for the full details, but the short version is that I am in the process of learning to program, and the projects page will keep a record of my initial attempts. I’ll be posting both the code I write and the apps I produce to that section for the foreseeable future as I make progress towards mastering a new skill. (Which is part of the mission of this blog, after all.)

My first project is a Pomodoro Timer (app; code). If you’re not familiar with the Pomodoro Method, it’s a very useful time-management system that involves alternating 25-minute periods of intense focus with 5-minute rest periods. And it’s very helpful for getting large amounts of mentally taxing work done quickly. Hopefully, my timer will help me use this technique more often.

The Blog Commitments project chronicles all the public commitments I’ve made. The commitment that is most relevant to the blog is that I’m committing to upload at least two posts to the blog every week. I use Beeminder to track and enforce these public commitments, and more details are available on their site. In addition to committing to blogging every week, I also have commitments about meditating, avoiding distracting websites at work, and coming home from work at a reasonable time. Again, full details on the respective pages.

For now, please feel free to use this page for any comments you have on the blog commitments or on my programming projects. I’ll have a substantive/analytical post up later this week (as required by my new Beeminder commitment).

4 thoughts on “Announcing programming projects & blog commitments”

  1. At the moment this seems to be the only place to give feedback regarding
    your Pomodoro timer.

    Storing the time components separately is unusual, awkward, and error
    prone. You should represent time as a flat count of some units,
    typically seconds or milliseconds. For example, a 25 minute timer is a
    1500 second (i.e. 60 * 25) quantity. For display purposes, you can
    convert this into MM:SS with a bit of arithmetic on the fly.

    You shouldn’t use setInterval() to actually keep track of the time. The
    delay is only the time between calls. That is, the browser doesn’t call
    the function precisely on the chosen interval. It calls the function,
    waits for it to finish, then sets a fresh timer to call the function
    again after the delay. While your function is running, time isn’t being
    counted. Worse, the timer isn’t particularly precise and your function
    will tend to get called a tiny bit late each time. This is especially
    true in a single-threaded browser (Firefox at the moment) where another
    busy tab can delay your timer function.

    Instead, you should only use the timer to update the display, relying on
    the system clock to keep track of wall clock time, which it’s really
    good at doing. This ties into the time representation above. You can get
    the current unix epoch — the number of seconds since Jan 1st 1970 — from
    a Date object:

    let now = Number(new Date());

    I lied. JavaScript operates in slightly higher precision, so this is the
    number of milliseconds in the unix epoch. When the 25 minute timer
    starts, you can use this to compute the end time:

    let end = Number(new Date()) + 1000 * 60 * 25;

    In the setInterval() function, use these two quantities to see
    how much time is left:

    let time_left_milliseconds = end - now;

    Do some arithmetic to extract MM:SS and draw it to the display. When the
    delta is zero or negative, time is up.

    Due to the imprecision of setInterval(), you may actually want to step
    it up to something smaller than 1 second, such as 0.1 seconds. This
    will more aggressively follow the actual time, being no worse than about
    0.1 seconds off for the display/interface.

    1. Thanks, all of that is very helpful! I know I’m at a very basic level at the moment, so I very much appreciate you taking the time to point out the better way to do things.

      I will revise the next version to set the timer up the way you suggest.

      One clarifying question: is there a reason your examples use let instead of var? A quick google search leads me to think that there’s no difference between let and var if I’m declaring them with global scope (as the current version does). Is that right, or am I missing something?

      1. var has been with JavaScript since its beginning, but let is relatively new (ES6, June 2015). var has a number of surprising quirks, such as only supporting function and global scope, and permitting variables to be accessed before their declarations (“hoisting”). Changing the semantics of var wasn’t possible without breaking existing code, so the standardization committee introduced a different keyword, borrowed from lisp, for the new semantics: let. It’s how var should have behaved from the start.

        Here in 2017, let is supported everywhere, so it’s good practice to always use let instead of var in new code. The only advantage for var was backwards compatibility, but that’s no longer the case. As you noticed, let is less relevant for global variables, but that link does mention one thing: let doesn’t put global variables on the window object. That’s also a good thing.

        Last year I threw together a retirement countdown for my father-in-law. It has a lot of similarity to your timer, so you may be interested in peeking at its source, too.

Leave a Reply

Your email address will not be published. Required fields are marked *