Don’t Bet Against Language Features

Remember when all the blogs in PHP land were telling you to use single quotes because double quotes are slow? I was a heavy PHP user at the time, and man I sure do. The advice was actually factually correct at the time, but has long been fixed in PHP, and it would never have mattered in your application anyways. I have seen this scenario play out again – this time with JavaScript Promises.

Be wary anytime you hear something along the lines of “use X instead of Y, because Y is slow” – where Y is a built-in programming language feature. This argument crops up from time to time, but it is almost always a complete non-issue in the long run. Continue reading

Stronger Encryption and Decryption in Node.js

If your encryption method produces the same encrypted result given the same original text input, your encryption is broken. Yet this is what I see in most other examples around the web on how to do encryption in Node.js. Strong encryption should always produce a different output, even given the same exact input. Continue reading

Titanium Proxy Objects With JavaScript Call and Apply

Sometimes language and platform abstractions bite you. They can seem pretty straightforward and “just like the real thing”, but sometimes they have odd behaviors that don’t quite work the way you expect.

Dynamic method invocation with .call() and .apply()

The .call() and .apply() functions are something you will use a lot if your code involves a lot of dynamic arguments, such as building an array of arguments that then need to be mapped to actual ordered function arguments in a function or method call.

Since Titanium runs native JavaScript with the V8 engine bundled in your app, you will naturally find yourself attempting things like this:

var args = [sql].concat(params);
var db ='dbname');
var rs = db.execute.apply(db, args);

But if you run that, and you will be presented with the head-scratching error:

invalid method 'execute:'

Although the error is pretty confusing – you know there is a method named execute on the db object – there actually is a good explanation for this behavior.

Titanium Proxy Objects

What intiutively seems to you like a normal JavaScript variable here – db – is actually a proxy object created and returned by Titanium with the call. Titanium also returns proxy objects for pretty much every other component that has a native counterpart they are bridging over to behind the scenes. This black magic is fundamental to how Titanium works internally.

The Solution

Although the main Titanium proxy object explanation suggests creating a wrapper object for the method call, that’s actually not necessary at all, and creates a lot of extra work, as well as many additional lines of code.

The best solution is to use a bit of JavaScript meta programming and call the apply method directly from the Function prototype:

var args = [sql].concat(params);
var db ='dbname');
var rs =, db, args);

This is a nice one-liner that achieves the same end result, is much easier to undertand, and does not require a wrapper object or another layer of indirection to achieve.

Count the Number of Object keys/properties in Node.js

When using the excellent formidable library to handle file uploads, I needed to get a count of the number of files unloaded in a multi-part form. Javascript arrays have a .length property that you can use, but objects do not. I instinctively typed:files.length

Which returned undefined. So if there is no length property present, an easy way to count the number of keys or properties of an object in ES5-compliant javascript environments like Node.js is to use the Object prototype directly:


A little more typing, but it is fast, efficient, and most importantly: already built-in.

The One Character Block Comment

When debugging, I often find that I have to comment and un-comment a block of code several times during the process of trying to find out what’s going on. That used to mean typing and deleting comment block characters repetitively, but not anymore. Here’s a simple solution to that problem: Comment or un-comment an entire code block of code by typing or deleting a single character.

I was able to arrive at this solution by combining the one-line comment with the comment block in a way that takes advantage of the rules the different types of comments have to follow.

Continue reading

jQuery UI Datepicker with AJAX and LiveQuery

I’ve been a little aggravated lately trying to get jQuery UI Datepicker to work correctly on dynamically added fields for creating additional line items to invoices for InvoiceMore. It works great for fields already displayed on the page, but it tends to have major issues with dynamically added fields through AJAX or AHAH. Of course it won’t work out of the box with elements added dynamically to the DOM, so we can use jQuery’s $.live() event (new in 1.3 – you previously had to use liveQuery) to make it work. The Datepicker works by binding to the focus() event by default, but as of jQuery 1.3.2, the ‘focus’ event cannot be monitored by the ‘live’ event function. So we’re stuck with a little work around:

You would think just a simple "$(this).datepicker()" call wrapped inside the live() event would work, but it doesn’t. Turns out that in order to get it working consistently, you have to add the ‘showOn: focus’ config option as well as manually focusing on the element with the focus() event. Charming.

Get the Most From Your Google Analytics Dashboard

main_logoI’m a big fan of Google Analytics.  The service is free, can go on multiple websites using just one account, and displays and processes stats beautifully. But the one thing that’s always annoyed me about Google Analytics is the default dashboard setup when you create a new website profile.

The dashboard is the place for the most important things to be. it should be the single place you can view to and get an overview of all the most important things about your website regarding your visitors without having to drill deeper or go through multiple pages or sub-sections.  But the default dashboard Analytics starts you off with is all wrong, and is almost never the information I really want to see.  Let’s see how we can fix this. Continue reading

Fixing IE7 Z-Index Issues with jQuery

For some reason, Internet Explorer 7 does some pretty funky things, and has several known bugs with it’s rendering engine that drive web developers like me crazy.  While most of the known bugs occur in relatively obscure situations and go largely unnoticed, there are a few that really stick out and cause web developers to waste many hours trying to fix them.  The way IE7 renders z-index stacking orders is one of them.

One way to fix many of the issues with IE7 is to dynamically reverse the default z-index stacking order of the elements on your page. This will ensure the elements higher in your HTML source will also have a higher z-index order on your page, solving most of the IE stacking issues. more If you’re using jQuery (the best Javascript library there is), here’s the quick fix:

$(function() {
     var zIndexNumber = 1000;
     $('div').each(function() {
         $(this).css('zIndex', zIndexNumber);
         zIndexNumber -= 10;

This code will start with a z-index of 1000, and decrement the z-index for each DIV element of the page by 10, giving the first DIV a z-index of 1000, the second, 990, the third 980, and so on. Notice that the selector will find all DIV elements with the code “$(‘div’)”, using the same syntax as CSS selectors. If your HTML code has different requirements, feel free to change the code or the selector to suit your needs by following jQuery’s documentation on selectors.

Update for MooTools


A generous commenter has posted the code for fixing z-index issues with MooTools 1.2:

if (Browser.Engine.trident){
     var zIndexNumber = 1000;
         zIndexNumber -= 10;