url::encode

Comments on programming, web development,
and computers by Titus Stone.

Immutable Arrays in Javascript

Most instance methods of javascript’s array perform mutations on the array.  Because objects are assigned by reference, this creates some odd situations…

var a = [1, 2, 3];
var b = a;
b.push(4);
// a == [1, 2, 3, 4]; 

When taking on functional programming practices, one of the first things is dealing with the mutation-based implementation of array methods.  Fortunately it’s possible to implement immutable methods along side the mutable methods and use those instead.

First up is a way to create a fresh array.

Array.prototype.clone = function() { return this.slice(0); };

It turns out clone-like functionality is built into the language, however it’s not labeled as such.  Slice returns a new array from the given dimensions.  That means if we slice an array starting at 0 then we’ll always end up with a new copy of that array.  Nice.

Using clone we can then implement immutable alternatives to methods.  It’s worth nothing that these so-called immutable alternatives really use mutation internally to achieve the results.  However, the end effect from “outside” the method is that they work like immutable methods.

Many javascript array methods have a return value of the array’s new length.

var a = [1, 2, 3].push(4);
// a == 4 

However in most cases what we really want is the new array being returned.

Array.prototype.ipush = function(x) {
    var a = this.clone();
    a.push(x);
    return a;
};

Using this syntax things work in immutable ways like we’d expect.

var a = [1, 2, 3];
var b = a.ipush(4);
// a == [1, 2, 3];
// b == [1, 2, 3, 4]; 

It turns out this pattern of cloning an array, calling a mutable method, then returning the new array is how all of these functions would work, so it’s possible to simplify this a bit.

All javascript functions include two functions, call and apply, which can be used to invoke that function.  In particular, apply takes two things, the “context” of what “this” should be and an array of arguments to invoke a function with.

For example:

function doStuff(x, y) { alert(x + ” and ” + y + “!”); }

// These are equivalent:
doStuff.apply(this, [‘foo’, ‘bar’]); 
doStuff(‘foo’, ‘bar’);

Why would that ever matter?  Well in this case we want to implement array methods as immutable but we don’t necessarily always know how many arguments each method takes.  We can circumvent this by turning the magical keyword arguments into an array, then using apply to invoke that function.

Putting that all together, here’s a way to implement immutable versions of array methods in one swoop:

[‘push’, ‘unshift’, ‘reverse’, ‘splice’].forEach(function(x){
    Array.prototype[‘i’+x] = function() {
        var na = this.clone()
          , args = Array.prototype.slice.call(arguments, 0);
        na[x].apply(na, args);
        return na;
    }
});

Tada.  We can now use these by simply prefixing “i” in front of each to get the immutable version.

var a = [1, 2, 3];
var b = a.iunshift(4, 5, 6);

// a == [1, 2, 3];
// b == [4, 5, 6, 1, 2, 3]; 

Programming Puzzle: String Length

Determine the length of a string without using any built-in “.length” or length getting functions.

Typical to true-engineering form, my first idea was overly complicated.  I had reasoned that I could write a recursive loop to progressively build up a 2nd string, then compare them to see if the lengths matched.  The problem there of course is that in order to do the comparison I have to use .length. #fail

After chuckling at myself for such an obvious oversight I realized there was a simpler solution.  A string could be treated as an array, and the first character could simply be shifted off recursively and the length determined that way.  A simpler implementation would be instead of converting the string to an array, simply using .substr(1).

function getStrLen (s) {
    var loop = function(acc, s) {
        if (s === “”) { return acc; }
        return loop(acc + 1, s.substr(1));
    };
    return loop(0, s);
}

Now that I’ve gotten used to tail recursion, it seems that I’m seeing uses for it everywhere.  I hope that’s a good thing…

FizzBuzz in F#

If you’re not familiar with what FizzBuzz is, check out this blog post by Jeff Atwood (Coding Horror).  FizzBuzz is sort of that bare-minimum-entry-level-bar that when you can clear you know you’ve at least understood the basic grammar of a language.  Typically I find in learning languages what takes the most time is really learning the standard library and built in functions.

F# has proven to be no exception to this and even though it has the entire .NET framework library behind it, there were some quirky things there to trip me up.  A great example is the printfn function.

Consider the following, which, though it seems like a trivial bit of code is actually wrong:

let x = “Hello World”
printfn x 

Running the above will thrown an exception…

The type ‘string’ is not compatible with the type ‘Printf.TextWriterFormat<’a>’

Really?  A string can’t be printed out?  There’s a question on StackOverflow which summarizes why this happens, but the short version is that printfn expects input to be of type TextWriterFormat<T>.  Right.

So the fix for the code above would be:

let x = “Hello World”
printfn “%s” x

I’ve been trying to write FizzBuzz in F# now for a week and while I probably have had it correct for a while, the printfn issue has been throwing me off this whole time.

In any case, here is FizzBuzz in F# (where the side effect of printing has been isolated to outside of the function):

let fizzbuzz n =
    match n with
    | n when n % 15 = 0 -> “FizzBuzz”
    | n when n % 5 = 0  -> “Buzz”
    | n when n % 3 = 0  -> “Fizz”
    | _                 -> n.ToString()

[1 .. 100] |> Seq.iter(fun x -> printfn “%s” (fizzbuzz x))

Appending to a List in F#

One thing about functional languages which sounds somewhat simple at first but turns out to be more complex is immutable values.  Variables (or “values” as they’re called in F#) can’t be changed once they’ve been initialized.

let x = 2
// This isn’t allowed:
x = x + 3 

Values in F# can be thought of as an equivalent to C#’s readonly accessor.

int readonly x = 2;
// This isn’t allowed:
x += 3;

The reasons for this are beyond the scope of this blog post.  However, while the idea seems simple it contains a few “gotchas”.

One such of these is appending to a list.  In C# this is quite a common task:

List<string> names = new List<string>();
names.Add(“Bob”);

There is no such thing in F#.  Instead there is the cons operator, ::, the syntax of which is:

element :: list

The result from the above is that cons returns a new list, with the element on the left being the first item of that new list and every item which was in list following it.  (Sidenote, the F# documentation actually has this incorrect.  It’s not appended.  Too bad it’s not a wiki.)

let x = [1; 2; 3;]
let y = 0 :: x

val y : int list = [0; 1; 2; 3;]

Cons is a much better performer.  The code doesn’t have to iterate over all the list items just to add the new one.  To illustrate why this is relevant let us suppose we needed the append functionality and we were going to implement it ourself.

We could start by reversing the list, then using cons to add what we want to be the last item to the beginning.

let a = [1 .. 3]
let b = 4 :: List.rev a

val b : int list = [4; 3; 2; 1;]

This gets us halfway, because even though our data is sequenced correctly, the list is in the wrong order.  We can fix that by once again reversing b into our final list.

let a = [1 .. 3]
let b = 4 :: List.rev a
let c = List.rev b 

val c : int list [1; 2; 3; 4;]

At this point it should be obvious why there is no append operator.  Internally the language would be doing this.  You might say, “but it needs to get done, so why not just have a language construct for it?”

Let’s say we refactored the above code into a function for re-use.

let append elem list = List.rev (elem :: List.rev list)

Great, now let’s use it in some code.  Let’s say we’re using tail recursion and an accumulator to make a list of CSS vendor/webkit prefixes.

let webkitify props =
    let rec loop list acc =
        match list with
        | head :: tail -> loop tail (append (“-webkit-” + head) acc)
        | [] -> acc
    loop props []

let props = [“border-radius”; “box-shadow”;]
let prefixed = webkitify props

Making use of the append function now, how many times is List.rev being called?  Within append it’s called twice which means that our simple function to prefix CSS properties with -webkit- calls List.rev twice for every item of the list (n * 2).

That’s really inefficient.  This is likely a big reason there isn’t an append operator.  Instead a very small change could be made to the function.  First, instead of appending items to the accumulator, the cons operator could be used:

let webkitify props =
    let rec loop list acc =
        match list with
        | head :: tail -> loop tail ((“-webkit-” + head) :: acc)
        | [] -> acc
    loop props []

let props = [“border-radius”; “box-shadow”;]
let prefixed = webkitify props

Then, once the loop has run out of items to recurse through the final result (the accumulator) can be reversed once.

let webkitify props =
    let rec loop list acc =
        match list with
        | head :: tail -> loop tail ((“-webkit-” + head) :: acc)
        | [] -> List.rev acc
    loop props []

let props = [“border-radius”; “box-shadow”;]
let prefixed = webkitify props

And there you have it: Why you don’t need an list append function.

Just for clarity, the above code is just for illustration purposes.  If you really wanted to add -webkit- to a list of props you’d use List.map, which composes a new list based on a function that is applied to every list item.

List.map (fun x -> “-webkit-” + x) props

F# is a Trip (or What is Function Currying)

For developers that have been living in javaland, javascriptland, or C#land for any lengthy period of time, the first encounter with a very functional language, it’s definitely weird.  F# is Microsoft’s latest language addition to their .NET kingdom.  It’s a functional/object oriented hybrid language which leans more towards the functional side and finds it’s roots in OCaml.

Quite frankly, it has some of the coolest features you’ll find on .NET at the moment, which head and shoulders above the rest of the .NET languages is the interpreter.  Further, the integration of the interpreter with Visual Studio reminds me of a Paul Graham quote from Hackers and Painters, (paraphrased) “programming languages should be for programmers to sketch in”.

It works like this:

Highlight code you’d like to execute
Press Alt+Enter
The code runs and the result appears in a console below the code, directly in Visual Studio 

As it turns out the interactive console is also great for language exploration.  The syntax of F# is a bit more minimal than you’d expect coming from C#.  Functions are defined just like values using an = where parameters aren’t wrapped in parenthesis.

let increment x = x + 1

Running that in the interpreter returns

val increment : int -> int

Two really important things are in that line.  First, F# inferred the type.  No where in the code is int specified as the type.  F# is a strongly typed language, but it will infer the type.

The second important thing is that F# returned to us the type signature of the function.  This type signature business is reminiscent of languages like Scala and Haskell.  int -> int — It basically means one integer is inputted and one integer is outputted.

But things get more interesting.  The increment function could be given a more broad usage.

let add x y = x + y

Interpreting the new function add returns

val add : int -> int -> int

That is not what one would expect.  The way the function is written is the average developer would expect a type signature of

val add : int, int -> int

But that’s not what F# is returning.  Reading the type signature, it appears that F# is interpreting the add function as two functions which it turns out is the case.  If the lack of ()’s on the functions was odd at first, then this is part of the reason why.  For each parameter on a function, behind the scenes F# makes a new function that returns a function.  (It’s not called a “functional language” for nothin’)

Why does all of this matter however?  Is it just compiler trickery or is there any use for this?  Because F# is internally creating a function for each additional parameter past the first one, if only some of the arguments were to be passed into add, what would be returned would not be a result, but another function.

Consider

let add x y = x + y
let increment = add 1

> val increment : (int -> int)

let a = increment 2

> val a : int = 3

The type signature for increment is int -> int!  Increment is a partially applied function.  It executions some of the parameters of add.

This is function currying.

It’s a trip.

LINQ is List Comprehensions in Disguise

I had a stunning realization last night.  LINQ is nothing more than Microsoft’s implementation of Haskell  list comprehensions (a language I greatly admire).  It’s not obvious this is what LINQ is, because Microsoft chose to change the keywords to be more SQL-like.

In Python or ECMAScript 6, a list comprehension can be written like so:

[x for x in set (if condition)]

Say for example you had a list of numbers and you wanted to find the value of them squared.  You could write something verbose like…

public List<int> Square(List<int> input)
{
    List<int> result = new List<int>();
    foreach (int i in input)
        result.Add(i * i);
    return result;
} 

List comprehensions would allow that to be written in a much more succinct way…

[x * x for x in list]

That’s much shorter and easier to tell the intent of what’s happening.  With a list comprehension, it’s also possible to add a conditional in there too.  For example, let’s say we only wanted to find the squared value where x was even.

[x * x for x in list if x % 2 == 0]

It turns out, this is what LINQ is.  Microsoft made a few changes however:

  • The first phrase in a list comprehension is typically the function to map against.  Microsoft moved this to the end of the statement and called it “select”
  • The “for” was renamed “from”
  • "if" was renamed to "where"

So we can take that exact list comprehension from a dynamic/functional language…

[x * x for x in list if x % 2 == 0]

And re-write it in LINQ…

from x in list where x % 2 == 0 select x * x

Do you see it?  It’s the exact same thing, though perhaps slightly more verbose.  LINQ == List Comprehensions.

When we talk about LINQtoSQL then, what we’re really talking about is “List Comprehensions to SQL” which on the surface seems like a really interesting idea (implementation aside).  LINQtoSQL is basically, given a data set, can a programmer succinctly express a list comprehension concept against it, with that concept being rendered into SQL.

Under the covers LINQ’s select is really just the functional Map.  Likewise LINQ’s aggregate is really just Reduce.  Using both of these it’s possible to write very functional code, strongly typed, with list comprehensions, in C#.  The odd part is that all of these excellent pieces were hidden under the covers of what looked to be a simple SQL-injected-into-C# project.  It’s not.  It’s much more than that.

Using a Custom Fork on Github with npm/Package.json

I just learned a really neat trick.  Have you ever had this situation come up:

You forked a public repo on github of an npm module and made some fixes or changes, but now you want to be able to use your fork in another project, perhaps even on Heroku?

Here’s how it’s done…

In the package.json file, replace the version of the npm module with the HTTP address of it’s github tarball.

// Change this:
    ...
    "dependencies": {
       "stylus": ">=0.1.0"
    }

// To this:
    ...
    "dependencies": {
        "stylus": "http://github.com/tstone/stylus/tarball/master"
    }

That’s it.  Pretty slick huh?

In Defense of Vendor-Specific CSS Prefixes

Sitepoint.com has been asking recently, “Should CSS vendor prefixes be abolished?”  The poll has been running on their front page for the past few days and as of the writing of this post 51% of respondents have said “Yes” versus 22% “No”.

I’m kind of surprised actually.  Likely the majority of respondents are web developers who would rather have the simplicity of typing in a single CSS declaration than 3 or 4 different ones (one for webkit, one for moz, one for IE8, and one for IE<8).  For however tempting of a world that would be with all CSS implementations unified I don’t think it’s going to happen.  Furthermore, if there was anything to learn from XHTML isn’t that theoretical standards don’t always translate into real world improvements.

An advantage of vendor-specific CSS prefixes is that it allows an HTML rendering engine vendor to experiment with a style implementation without breaking the implementations other browsers provide.  Roll back the clock 8 years and this was a pretty big deal.

Consider, for example, HTML Engine “A” decides to implement an experimental CSS prefix “tween-animation”.  It allows a developer to implement simple tween animations using CSS…

.heading { position: absolute; tween-animation: 10px, 10px, 50px, 50px; }

Mind you this is all hypothetical.  So engine “A” implements this and you start using it on your site.  Then later HTML Engine “B” also decides to do an implementation, but they decide to implement it differently.  Now what?  Your .heading tween-animation which works in Engine “A” now does weird stuff in Engine “B” except you have no way to specify that it’s only for Engine “A”.

Bam.  That’s where vendor prefixes come in.  Not only does it allow for new CSS experimentations but it does so in a way that won’t break in the future.

There are many other good reasons to maintain vendor-specific CSS prefixes.  The discussion happening on the Sitepoint blog is a good place to start if you’re interested in more.

Converting PNG Images into HTML

A while back I wrote a short python script to take any PNG image file and convert it into pure HTML.  Yes, pure HTML.

This actually started as an office joke with the query of how do we put the company logo into emails for people who don’t have images enabled.  It was a natural downward progression of jokes that eventually lead to converting the image into HTML.  Aaaaaand as any dynamic language programmer in a Microsoft shop I knew I could probably whip up something in an hour or so.

My first few attempts didn’t work too well because I actually generated too much HTML.  It seems that after about 2.75MB of HTML, browsers tend to choke and die when rendering it.  So after the first initial hour of getting it to work, the remaining time was spent on compressing the HTML into a manageable portion for the browser.

The script uses <b> tags to represent rows and <a> tags to represent individual pixels (chosen because they’re short).

The script is smart enough to figure out that if two “pixels” next to each other are the same color, instead of adding a new <a> tag, it can simply increase the width of the <a> tag to the left.

Here’s a rendered sample of the output (using my wedding photo of all things) and you can see the reproduction is very faithful to the original.  The script itself is included below.

Non-Intrusive Javascript Hovers by Convention

As I’ve been learning Rails lately, the value of convention-over-configuration has been becoming more apparent to me.  Here’s a quick example of how you can use this principle to speed up common tasks in web development.

For demonstration, let’s use a really common task:  Making mouse over hover effects.  I’ll be using jQuery but you can use the JS framework of your choice.

The Simple Way

Each time we want an element to have a hover effect, we need the following code:

/* CSS */
button { font-weight: normal; color: #000; }
button.hover { font-weight: bold; color: #333; }
<!-- HTML + Javascript -->
<button id="mybutton">Click Me!</button>
<script>
    $('#mybutton').hover( function() {
        $(this).addClass('hover');
    }, function() {
        $(this).removeClass('hover');
    });
</script>

Sure, that’s easy enough, but it’s cumbersome to implement all of that every time, it’s ugly to have javascript scattered all over your page, and it probably isn’t resource-efficient if the user has to download that script (however small) every page view.

Improving it with a plugin

The first thing we could do to reduce effort would be to re-factor our code into a plugin so that it’s reusable by a single call….

$.fn.hoverClass = function(cssClass) {
  $(this).each(function() {
    $(this).hover( function() { $(this).addClass(cssClass); }, function() { $(this).removeClass(cssClass); } );
  });
  return this;
};

This gives us much shorter code when implementing a hover behavior…

<button id="mybutton">Click Me!</button>
<script>
    $('#mybutton').hoverClass('hover');
</script>
Introducing a convention

So we’re doing better but we can introduce our first convention-over-configuration here. We can agree with ouselves that “hover” will be the default name of the hover class. This is a good start. Our hover behavior implementation is getting smaller…

<button id="mybutton">Click Me!</button>
<script>
    $('#mybutton').hoverClass();
</script>

…but we’re still being rather redundant: every time we want to implement the hover behavior we need to call our hoverClass method. What would be better is if we could simply annotate which elements recieved the behavior. If we introduce a 2nd convention this can be possible.

Annotating elements through markup

There are a handful of ways to annotate tags for certain things. A popular route is to use CSS classes. This is a perfectly plausible route, but I think I’m going to make use of the new HTML5 data attributes instead. There is an advantage to using them instead which I’ll show you in a second.

So let’s develop a convention for marking tags as the ones we want to have the hover behavior on. The simplest would be to add an attribute to the tag: data-hover.

<button id="mybutton" data-hover="">Click Me!</button>

With jQuery we can easily find every tag that has this attribute by using wildcard and empty attribute selector “*[data-hover]”. Since we’ve created this convention now, we can activate the plugin to all those elements on DOM ready…

$.fn.hoverClass = function(cssClass) {
  $(this).each(function() {
    $(this).hover( function() { $(this).addClass(cssClass); }, function() { $(this).removeClass(cssClass); } );
  });
  return this;
};

// On DOM Ready...
$(function(){
  $('*[data-hover]').hoverClass();
});

And with that we’ve removed the need to have a <script> tag following every element on our page that needs this behavior. But still we can improve upon this. Occasionally we’ll run into situations where we don’t want to use the .hover class to implement the effect but something else. Here’s where using HTML5 data attributes vs. CSS class names comes to play.

Breaking out of the convention

In the data-hover=”” attribute we can optionally specify a value. Using jQuery we can check if that value is available and use that as the hover class instead of ‘hover’

$.fn.hoverClass = function(cssClass) {
  $(this).each(function() {
    $(this).hover( function() { $(this).addClass(cssClass); }, function() { $(this).removeClass(cssClass); } );
  });
  return this;
};

// On DOM Ready...
$(function(){
  $('*[data-hover]').each(function() {
    var hc = $(this).data('hover') || 'hover';
    hoverClass(hc);
  });
});

With this setup you have the choice to take the default or specify a custom hover class…

<button id="mybutton" data-hover="">Click Me!</button> <!-- Take the defaults -->
<button id="mybutton" data-hover="custom-hover">Click Me!</button> <!-- Use this class instead -->
Wrapping up loose ends

If you’ve done a lot of javascript development you may have noticed a shortcoming in the way we’re approaching this. Our handle little convention runs once on DOM load and never again. This means if we create new DOM elements after page load or if we have content that’s loaded through AJAX which contains these data-hover marked elements they won’t having .hoverClass applied to them.

There’s three ways that we can go about fixing this.

The first is to just call $.hoverClass on any new elements we make. But the issue here is how do we know which elements to call it on? There’s a better way…

The second way to handle this would be to re-factor our DOM ready code into its own jQuery plugin which we can call at any time.

$.fn.hoverClass = function(cssClass) {
  $(this).each(function() {
    $(this).hover( function() { $(this).addClass(cssClass); }, function() { $(this).removeClass(cssClass); } );
  });
  return this;
};

$.fn.autoHoverClass = function() {
  $('*[data-hover]').each(function() {
    var hc = $(this).data('hover') || 'hover';
    hoverClass(hc);
  });
};

// On DOM Ready...
$(function(){
  $.autoHoverClass();
});

This is a decent route as we retain all “auto” functionality but with the ability to refresh the automatic functionalty after we’ve changed some page content. Still yet, jQuery 1.4 provides us with another way…

jQuery 1.4 introduced the .live method which I previous mentioned in a blog post. The .live method is a replacement for .bind with the exception that it will bind events for all current and future elements. It’s a bit dizzying to imagine how this works internally, but given a jQuery wrapped set we can make sure the event handler is always “hooked up”.

To do this though requires us to re-factor our code a bit. For one our code is written to call .each then to call the event binders. This is a problem because .each isn’t updated “live”. The solution is to move the event binding code so that it’s on the wrapped set then to evaluate the value of data-hover within the event handling code.

$('*[data-hover]').live('mouseover', function() {
  $(this).addClass($(this).data('hover') || 'hover');
});
$('*[data-hover]').live('mouseout', function() {
  $(this).removeClass($(this).data('hover') || 'hover');
});

For simplicity I dropped the jQuery plugin syntax to be clear about exactly what’s going on. I’ve tested doing it this way, and while it does work it can cause noticable browser lag ad whenever new DOM elements are added or removed. For this particular use-case I don’t feel the performance impact warrents what we’re using it for, but know it is an option.

Final code

So our final code that we ended up with for hover behavior by convention is….

// separate-js-file.js
$.fn.hoverClass = function(cssClass) {
  $(this).each(function() {
    $(this).hover( function() { $(this).addClass(cssClass); }, function() { $(this).removeClass(cssClass); } );
  });
  return this;
};

$.fn.autoHoverClass = function() {
  $('*[data-hover]').each(function() {
    var hc = $(this).data('hover') || 'hover';
    hoverClass(hc);
  });
};

// On DOM Ready...
$(function(){
  $.autoHoverClass();
});
<!-- In your markup -->
<button id="mybutton" data-hover="">Click Me!</button>