April 8th, 2010
While debugging a caching class today, I realized that I had finally been caught by semicolon insertion.
Here’s the original code cut from a larger object literal
isValid: function(hash) {
return
// Is cached AND
typeof this.entries[hash] != "undefined" &&
// Cache doesn't expire (e.g.: -1) OR hasn't expired yet
(this.entries[hash].expires < 0 || this.entries[hash].expires > new Date().getTime());
}
After about 10 minutes and a gratuitous amount of debug output, I realized that this function was returning `undefined`. “Nonsense,” I said to myself, “it’s returning a boole…wha…wait. Dammit.”
In my effort to document and format at the same time, I dropped the expression to the next line after the `return`. Being that `return` by itself on a line is a complete and valid expression, JavaScript’s automatic semicolon did its thing and ended the statement there and my conditional expression was never evaluated.
Wrapping the whole conditional expression in parenthesis fixed the problem by invalidating the `return` line as a whole statement.
isValid: function(hash) {
return (
// Is cached AND
typeof this.entries[hash] !== "undefined" &&
// Cache doesn't expire (e.g.: -1) OR hasn't expired yet
(this.entries[hash].expires < 0 || this.entries[hash].expires > new Date().getTime())
);
}
Let that be a lesson to us all. I suppose it was bound to happen at some point.
Tags: bugs, dammit, JavaScript, semicolon insertion
Posted in JavaScript | 4 Comments »
March 21st, 2010
If programmers can agree on one thing, I think it’s that new languages are good to learn. And why not? Exposing yourself to new ideas helps you grow and refine your skills as a professional or hobbyist as the case may be. Practically speaking, it gives you a larger skill set which can make you more hire-able and might even increase your pay. But all that’s besides the point: I want to learn something new
So after some farting around with a couple of different candidates, I’ve decide to learn me some Python. The runners up were Haskel and node.js. Although incredibly interesting and a whole new way of thinking (functional vs procedural, that is), Haskel doesn’t seem like it would be immediately useful or practical. As for node.js, since I already know JavaScript well, it’s more of just learning an API rather than a new language, which doesn’t seem like much of a stretch, but I’ll probably still tinker with it. Read the rest of this entry »
Tags: functions, learning, Python, strings
Posted in Python | 5 Comments »
July 7th, 2008
Whether it’s an internal or external project, for coworkers or clients, the trap of being the boy who cried “wolf”, or in this case, the developer who cried “done,” is an easy one to fall into. The issue here, besides an elongated development time, is that this trap cuts at our credibility as programmers, even—and especially—when the circumstances are out of our hands. If you say it’s done, it’d damn well better be done. So, to avoid such an incredulous rap, try following these steps to make sure that projects actually get completed on time, the first time. Read the rest of this entry »
Tags: client projects, coworker projects, development cycle, pit falls, progamming cycle, project appraisal, project management, solutions, specifications, thinking ahead, understanding problems
Posted in Development, Management | 2 Comments »
July 6th, 2008
Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.
As a programming department, it is always our goal to code in such a manner that makes use of methods that provide, on average, the fastest execution times. In today’s discussion, we’ll be testing the many different ways to process and interact with arrays in PHP in the first of three main areas: reading, modifying, and reconstructing. Read the rest of this entry »
Tags: arrays, benchmarking, iteration, loops, Optimization, PHP, speed
Posted in Optimization, PHP | 1 Comment »
July 5th, 2008
Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.
When we talk about topics such about CSS, JavaScript, and sometimes even certain image formats (png24, I’m looking at you), and how they render in a client’s browser, we always, or should always also consider cross-browser behavior. This behavior entails many things: CSS rendering, the availability of CSS specific attributes, whether or not the DOM interface will be the same, general JavaScript behavior — the list goes on and on. And, since most discussions about CSS and JavaScript (at least the ones that I am having) also concern this variable nature, I’m coining (maybe I’m the first) a new term to put all of this into a handy little phrase, “Cross-Browser Consistency,” or, in typical programmer fashion, simply, “XBC.”
Let’s take a brief moment to establish a more exact meaning for this phrase. As you may well be aware, the industry commonly talks about cross-browser support, so we’ll differentiate between support and consistency, as well as defining what cross-browser really means, and some other tidbits as to boot.
Read the rest of this entry »
Tags: consistency, cross-browser, CSS, firefox, functionality, HTML, internet explorer (ie), libraries, markup, noscript, operating systems, resolution, scalability, standards, support, xbc, xslt
Posted in CSS, Cross-Browser Consistency, Development, HTML, JavaScript | 3 Comments »
July 4th, 2008
Today, we’re talking about color, its use on the web and how it is (in)effectively rendered cross-browser and cross-platform. Read the rest of this entry »
Tags: color, CSS, firefox, images, internet explorer, palette, rendering
Posted in CSS, Cross-Browser Consistency, HTML | 3 Comments »