Category: JavaScript

Posted on

Jack Has Problems With His Dates

A long time ago, Jack needed a function to return a JavaScript date object which represented New Year’s Day for any year which he specified, or for the current year if none was provided.

This is what he came up with:

function getNewYearsDate(yr){

	var nyDate = new Date("");

	if ( typeof yr === "undefined"){
		var tmpDate = new Date();
		yr = tmpDate.getFullYear();
	}

	nyDate.setMonth(0);
	nyDate.setDate(1);
	nyDate.setYear(yr);

	return nyDate;
}

Of course, Jack tested his function carefully . . .

getNewYearsDate(2020);
// returns Wed Jan 01 2020 00:00:00 GMT-0500 (Eastern Standard Time)
getNewYearsDate();
// returns Tue Jan 01 2019 00:00:00 GMT-0500 (Eastern Standard Time)

and seeing the results he expected to see, Jack pushed this change to production where it worked wonderfully for many months.

This morning, Jack identified a need for a similar function which represents July 4th/Independence Day. Because Jack is in a rush, he decides to copy and alter his getNewYearsDate function to handle returning the date for Independence Day in the United States (July 4th).

Here’s what he did:

function getIndependenceDate(yr){
	
	var idDate = new Date("");

	if ( typeof yr === "undefined"){
		var tmpDate = new Date();
		yr = tmpDate.getFullYear();
	}

	idDate.setMonth(6);
	idDate.setDate(4);
	idDate.setYear(yr);

	return idDate;
}

But this time, when he tests his new function, he gets surprising results!

getIndependenceDate()
Tue Jan 01 2019 00:00:00 GMT-0500 (Eastern Standard Time)
getIndependenceDate(2020)
Wed Jan 01 2020 00:00:00 GMT-0500 (Eastern Standard Time)

Can you see why the getNewYearsDate() function works, while the getIndependenceDate() function fails?

If so, how would you alter the getIndependenceDate() function so it returns the correct value?

Posted on

New Github repo: URLParams

I spent more time than I’d have liked last week fixing an issue related to the intermittently incorrect appending of UTM parameters to URLs. Basically, the code worked fine if the link was “basic”, but if it already had  parameters, a second question mark would get added. Since URLs cannot have two question marks, the link would break.

Adding parameters to links sounds simple, until you “roll your own code” and discover issues like– making sure your parameters are URL encoded, and checking to see if the link already has parameters, etc. I decided to capture these hard-won lessons in a JavaScript class called URLParam, and it’s freely available at GitHub.  (It’s worth mentioning– although ES6 classes enjoy wide support across Chrome, Firefox, Edge, Safari, etc., they are not supported in any version of Internet Explorer.)

I hope you’ll find this useful– both in the sense of finishing a coding task faster, and having fewer issues to resolve after deployment.

Posted on

Book Review: HTML5 Applications

I picked up Zachary Kessin’s book, HTML5 Applications, at a used bookstore and tried to read it recently. It was not a pleasant experience.

To be fair, this book was published in 2011 and a lot of the specific details have changed in the seven intervening years.  The BlobBuilder() function, for example, has been subsequently deprecated. It would be unreasonable to expect a printed book to anticipate and adapt for this kind of change, obviously, and I don’t fault the author for this.

Here’s an example of the kind of frustrating problems I had with the book in addition to the material being changed:

Because JavaScript is a case-sensitive language, the correct methods should be fadeIn and fadeOut, rather than all lower case. Granted, developers already familiar with jQuery will know this and adjust accordingly, but a technical reviewer should have caught this and set it right before it got to print.

Similarly, in a later portion of the book where Kessin is explaining the filter() method, an even function is referenced– even though it is never defined anywhere else on the page. Again, an experienced JS developer will be able to infer the need to define an even() to make the code work, but expecting readers to “just know this” and “fill in the blanks on their own” doesn’t contribute to a positive reader experience. It’s precisely these sorts of omissions which make learning new material frustrating instead of enjoyable, because you feel like you’re spending more time fixing someone else’s code rather than learning new material.

The section on Testing JavaScript Applications with QUnit and Selenium were fairly decent, and some material in the New Tags chapter was helpful, but I’ve found it necessary to put notes in the margins of several pages to keep track of omissions and updates.