I hate to admit it, but I do read Stephen Chapman's Blog, and to be honest I tend to find a lot of the things he covers as incomplete, or outright not the best way to do something. A lot of entries are simple repeats of past entries as well. In the past I've had comments censored, specifically when he stated that you should just ignore IE in a prior post, I had a bit of a strongly worded response. In any case, today's entry covered Optional Function Arguments. There's one small point he missed the boat with here regarding the arguments instance.

"That is as far as the similarity to arrays goes though as none of the other methods and properties that can be used with arrays can be used with the arguments object."

It is possible to easily convert the arguments object to an Array instance though. Here's a simple example.

function argumentsToArray() {

  //convert object arguments to args Array
  var args = Array.prototype.slice(arguments, 0);

  //alerts true
  alert(args instanceof Array);

}

I've thought about, and may actually do more of these annotation posts. I've also been thinking about doing some compilation posts with information from Ajaxian, DailyJS and a few other sites.

Okay, this is a quick one. There are several states that can be considered empty in JavaScript, a non-numeric value in a number, an invalid date, and empty string, an undefined value, and a null value. The issue is that some of these require testing against isNaN, and others will evaluate as matching null or an empty string (ex: the number zero and the boolean false). What I wanted was a simple method to check for a non-empty object or string, here it is.

function isEmpty(obj) {
    if (typeof obj == 'undefined' || obj === null || obj === '') return true;
    if (typeof obj == 'number' && isNaN(obj)) return true;
    if (obj instanceof Date && isNaN(Number(obj))) return true;
    return false;
}

How it works, is first it tests for an 'undefined' object, an object that is explicitly equal to null, or explicitly equal to an empty string. If it matches, it's empty. From here there's some more specific checking, if it's a number type of variable, and isNaN (Not a Number), then it's empty. If it's a date, and Number(obj) (which gets the value of the date as a Number) isNaN, then it's an invalid date, and ergo isEmpty. Otherwise the isEmpty returns false (valid, non-empty value). Hope this helps some of you. :)

Okay, so you really want to be able to have some of your JavaScript methods to have access to a variable that is private, but maintains state between calls. The first piece of knowledge, is that you can have the contents of a function execute itself at runtime.

(function(){ /*Your actions here*/ })();

This is a very common method of defining complex classes and libraries, that can have their own variables or methods that aren't otherwise available to the object model outside this closure. When you utilize "this" within the function's closure it will be default to the global object, which in the Browser DOM is "window".

(function(){
    this.test = "Test Value";
})();
alert(test); //alerts "Test Value"

Usually when creating libraries in JavaScript it's a good idea to create namespaces for your library. More...

Okay, so you want to utilize some of the niceties of the new EcmaScript 5 extensions to Date.  Namely they've added a nice instantiation from an ISO-8601-style string, as well as a Date.prototype.toISOString method definition.  In addition there are Date.UTC and Date.now methods defined.  As the nice guys over at Mozilla have offered script based extensions to Arrays to support their method extensions there, I wanted to do something similar for Date instances.  I've managed to do this, and have had it done since the ES5 specs were released, but figured I should put this out there for anyone interested.

var epoch1 = new Date("1970-01-01T00:00:00.000Z");
var epoch2 = new Date(0);

if (epoch1.getTime() == epoch2.getTime())
    alert("Epochs match!");
    
alert(epoch1.toString()); //localized date instance of the JS epoch
alert(epoch2.toISOString()); // "1970-01-01T00:00:00.000Z"
alert(epoch1 instanceof Date); // true
alert(epoch1.constructor == Date); //true
alert(Date.UTC(1970,0,1,0,0,0,0)); // 0

I also have a few convenience methods for handling Microsoft's JSON encoded strings. As well as rolling a date from a "Local" or "UTC" version.

DateExtensions.js (11.67 kb)

Edit 2010-01-08: I added missing support for .constructor == Date

If intelectual property in this country is to be treated and protected like real property, then why isn't it taxed as real property.  Why aren't infringement settlements taxed at the point of transaction,the same as with physical goods?  If we are so short of funding for government programs, why isn't the copyright and patent industry taxed like the physical production industries?

Okay, it's a TV, but I'm only using it as a montitor.  It's currently connected to my computer via DVI-to-HDMI and works pretty well.  I'd been thinking about doing this since the 32" LCD TV's with 1080p started getting pretty reasonable in price.  It doesn't have the super resolutions of some computer monitors, but 1920x1080 is enough for me to work with, and this way the image is larger, instead of most things just being rendered wrong, or stupidly small, at least for now.  I went with a 42" LG (Model 42LH50) display.

For comparison's sake, that is a Unicomp Customizer 104 keyboard (IBM Model M Style).  The thing is freakishly huge, and I love it.

Just in case anyone else needs it, here's my method for getting the millisecond offset of a server's local time to UTC time in milliseconds, for use in client-side JavaScript.

private int ServerSideJsUtcOffset
{
    get {
        DateTime epoch = new DateTime(1970,1,1);
        int offset = (int)epoch.ToUniversalTime().Subtract(epoch).TotalMilliseconds;
        return offset;
    }
}

There's really not much to it, it's mainly so that I can handle converting serialized dates to a proper local time on the client. The DateTime objects in question are stored in a database as the UTC date-time, via an ORM tool, and sent to the client with System.Web.Script.Serialization.JavaScriptSerializer. All the server-side code uses the same ORM tool, and all the client-side JSON is processed via the same local parser. So it was simply easier adjusting the client-side parser than it was to adjust the server-side class hierarchy.

I should note that I could have set the initial date to DateTime.Now instead of implicitely using the JS epoch, as the difference would be the same for any localized DateTime, just felt the clarity was worth it.

Okay, this started when I wanted to store a bit of JSON that gets rendered into the ASP.Net cache.  Each entry would be unique to a given user, and I wanted to save a little memory, each entry would be about 8KB in size.  I looked into this and found the System.IO.Compression namespace that is available in .Net 3.5.  I created a small class with some helper extensions to be able to compress/decompress an array of byte, and handle to/from a native string.  Here's what I came up with.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.IO.Compression;

namespace Sample
{
    public static class CompressionExtensions
    {
        const int KB = 1024;

        public static byte[] Compress(this byte[] input)
        {
            using (var ms = new MemoryStream(input.Length + 8))
            {
                ms.Write(BitConverter.GetBytes(input.Length), 0, 4); //record original length

                if (input.Length < KB)
                {
                    //if less than 1KB, don't compress original
                    ms.Write(input, 0, input.Length);
                    return ms.ToArray().Take(input.Length + 4).ToArray();
                }

                //compress the original input
                using (var ds = new DeflateStream(ms, CompressionMode.Compress))
                {
                    //send the original input to the compressed stream
                    ds.Write(input, 0, input.Length);

                    //add null padding. the decompress gets wonky without it.
                    ds.Write(new byte[4], 0, 4);
                    ds.Flush();
                    ms.Flush();
                    return ms.ToArray();
                }
            }
        }

        public static byte[] Decompress(this byte[] input)
        {
            if (input == null || input.Length < 4)
                throw new ApplicationException("Invalid compressed bytes, no length header.");
        
            var bitlen = BitConverter.ToInt32(input, 0);

            //if less than 1KB, return the non-compressed original
            if (bitlen < KB) return input.Skip(4).ToArray();

            var buffer = new byte[bitlen];
            using (var ms = new MemoryStream(input.Length - 4))
            {
                ms.Write(input, 4, input.Length - 4);
                ms.Flush();
                ms.Seek(0, SeekOrigin.Begin);
                using (var ds = new DeflateStream(ms, CompressionMode.Decompress))
                {
                    //this always returns a -1 for the first read
                    //    subsequent reads will work properly
                    ds.ReadByte();

                    //read the input stream into the return buffer
                    if (bitlen > ds.Read(buffer, 0, bitlen))
                        throw new ApplicationException("Invalid compressed bytes.");
                }
            }

            //only return the number of bytes originally saved, trim excess
            return buffer;
        }

        public static byte[] ToCompressedBytes(this string input)
        {
            return Encoding.UTF8.GetBytes(input).Compress();
        }

        public static string ToDecompressedString(this byte[] b)
        {
            return Encoding.UTF8.GetString(b.Decompress());
        }
    }
}

I found that without adding some padding of at least two null bytes, the decompression of the data would sometimes give me an invalid final byte. I also push in a 4-byte length header for a sanity check. This also helps me to not compress anything under 1KB in size, where compression really doesn't work very well.

The conversion of the string to UTF8 helps more with strings that will mostly contain values within the ASCII character set. It is worth noting that if there are mostly multibyte characters, the byte array itself could get bloated. For my usage, I'm getting an 8KB string down to around 2KB, you could extend this to support UTF8/Unicode encoding by appending a character to the end before compressing. This may be useful if the string is >2KB and more than 1/3 is multibyte characters, this would take a little more CPU time to inspect the input string in this case.

Your milage may vary. Void where prohibited. Quantities limited. Some restrictions may apply. Batteries not included.