JavaScript single-threadedness and timers

If you’re coming from a programming language that has support for multithreading and concurrency, (such as Java) then understanding the flow of asynchronous events in JavaScript such as timers can be a bit confusing.

However, once you understand the single-threaded nature of most JavaScript, things may actually becoming easier as you don’t have to worry about parallel access to non-local variables.

Let’s take a look at how JavaScript executes when a function is passed to window.setTimeout().


Analysis of the 2013 Chicago Marathon results

With close to 39,000 results, the 2013 Chicago Marathon Results combine two of my favourite topics, statistics and running. I decided to take this opportunity to learn more about pandas by using it to analyze the result set to provide some insight into how people run marathons. (I myself ran this race)

The result of my work is in a GitHub repo and published as an IPython Notebook. I’ve extracted some of the more interesting parts.


Spring MVC request parameter conversion with minimal configuration

I’ve been playing around with Spring Web MVC a bit and was looking for something similar to Jersey’s Parameter Classes that would provide conversion to custom types. I liked how with Jersey, you could encapsulate the conversion logic in a single class and have that reused across multiple methods with minimal configuration.

Here’s how I achieved a similar result in Spring Web MVC. (Note: the following examples were done with Spring 3.2.1)


Java: final, finally and finalize

One of the most popular Java interview “screener” questions is often, “What is the difference between final, finally and finalize?” In fact, it occurs so much that one should probably have the answer memorized. But knowing when to use these features is better than just knowing what they mean.


JAX-RS/Jersey needs an @Required annotation for parameters

I’ve been using Jersey as a JAX-RS implementation for a little while now, and one thing that it could benefit from is the addition of an @Required annotation for resource method parameters. Right now, when parameters are not provided by the client/request, they are simply set to null, creating the need for duplicated null-checking in resource methods. An @Required annotation would solve this issue and reduce code duplication.

This isn’t so much of an issue for @PathParam parameters, (since you won’t even get to the proper resource method without a matching URI) but it does affect @HeaderParam and @QueryParam (among others) since they aren’t needed for Jersey to determine which resource method to invoke. By that definition, they are implicitly optional. There should be a way to make them required.

The behaviour of such a required annotation might be as follows:

  • If the request does not have the parameter, then by default a Response with Status.BAD_REQUEST (HTTP 400) would be returned to the client.
  • Some way of customizing the HTTP response code and message should also be provided.

Right now, there’s not really an elegant way to make something like a @HeaderParam required. Here are some solutions I’ve tried.

Java’s Pattern class and regular expressions

One of the easiest things to get tripped up on is the syntax for creating regular expressions (regex) in Java using the Pattern class. The tl;dr version of how to do things is that you must use double-backslashes in the regular expression Strings you use to create a Pattern object; so something like \b would have to be written as "\\b". Read on for a more thorough explanation.


The Game of Life and emergence

I have had a side interest in emergent behaviour ever since reading about various forms in nature, so when a co-worker sent me a link to Conway’s Game of Life, I was immediately intrigued.

Long story short, I just had to implement it (albeit a simple version) in JavaScript. The result is available on my website and I suggest you give it a try; a good pattern to start out with is the F-pentomino.

The reason I find emergence so interesting is that it provides a possible framework or explanation for the complexity and order seen in our universe, based on a fairly simple or rudimentary set of rules.


Shuffle sort and other fallacies of randomization

Quick, how do you write code that shuffles a collection of objects? In the real world, it’s fairly easy to see how a deck of cards is shuffled – but how would you do that in code? Obviously, you would have to use some sort of random number generator, but beyond that it’s not straightforward. Furthermore, how do you ensure that the shuffling is fair; that is, all permutations appear with equal probability?

The astute among you will know that one way is by implementing the Fisher-Yates shuffle algorithm. But, let’s investigate what happens when other, seemingly adequate solutions, are used instead.


The Flyweight Pattern: (Mis|ab)used at times.

In my brief career in software development thus far, I have seen a lot of “WTF” code, that is, code that deserves to be posted to The Daily WTF. Some of this code was admittedly developed by myself and upon reviewing it a few months after it was written, I secretly wondered what I’d been thinking.

This isn’t going to be an indictment of bad programming; in fact, I think it’s good if you can look back at your old code and see where it could be improved. Such a process suggests that you are continually self-improving, a skill crucial in software development. Besides, all of us have made a mistake or two at times when we were stressed, tired or just plain not thinking straight.

However, there’s one mistake that I’ve seen that I think warrants bringing to light, and that is the misuse of the Flyweight pattern.


Goodbye, old friend…

I’ve had the same pair of prescription glasses since about 2004, having changed the lens more than once. I just got so used to them that whenever the opportunity arose to replace them, I couldn’t find a pair that felt or looked right. So, I just continued with the same old dependable pair.

They’ve fallen off of my face more than once, have tumbled many times to the hardwood floor from my nightstand while I fumbled for them in the dark, been lost in my bed covers and rolled onto during numerous occasions, and of course I’ve fallen asleep with them on more times than I can remember. Despite all of this, they not only held together, but retained much of the original lustre and remain in excellent condition.

Only one of the earpieces is starting to look worn, the nose pads are looking a little old and one of the lens screws had to be replaced when it fell out and got lost, but other than that, they’re as good as new. This was the first “thin” pair of glasses I had ever worn and I initially had some reservations about durability, so I’m more than pleased with how well they’ve held up. (I think the frames are made up of some titanium, but I can’t remember)

But this past weekend, I decided it was time to finally replace them.

We’ve had a good run, old friend, but I’m afraid it’s time to part ways.


View all entries by month or by category