url::encode

Immutable Arrays in Javascript

Wed, 22 Feb 2012 21:31:00 -0700

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

Tue, 21 Feb 2012 22:27:00 -0700

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#

Sat, 18 Feb 2012 08:23:51 -0700

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#

Wed, 15 Feb 2012 23:11:00 -0700

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)

Sat, 11 Feb 2012 06:15:00 -0700

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

Thu, 09 Feb 2012 20:45:00 -0700

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

Sat, 04 Feb 2012 06:58:45 -0700

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

Sat, 20 Nov 2010 08:56:00 -0700

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

Thu, 18 Nov 2010 07:26:51 -0700

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

Tue, 16 Nov 2010 19:48:00 -0700

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>

Why Writing a Webapp Reminds me of Playing a RPG

Sun, 07 Nov 2010 12:54:44 -0700

I’m sure you’ve played an RPG of some sort… Diablo, Torchlight, Titan’s Quest, City of Heroes, World of Warcraft, Pirates of the Burning Sea, Aion, Eve Online, Dark Age of Camelot, Age of Conan, etc. These all invariably involve the same pattern of gameplay.

You design a character — it’s gender, appearance, skin tone, and of course role/class. You enter the world, simple and weak, using the same basic skills to accomplish every task. As you grown in experience you begin to use more tools to accomplish the same tasks. In the “middle” portion of this experience, between when you first created the character and the maximum level is probably the highlight of playing: You’re progressing at a very notable pace, you frequently receive gear upgrades and new skills, and the sense of accomplishment is very high. As you start to near level cap the “newness” begins to wear off: you only receive more powerful versions of the spells you already had. There isn’t anything new, just bigger numbers. Hitting level cap the sense of accomplishment trails off very fast. The only progression left is to try to acquire more and more esoteric pieces of gear/upgrades. The time between those upgrades becomes farther and farther apart as more time investment is required to attain them.

I see a lot of similarities with writing a webapp. You start off designing your technology stack — it’s web server, server framework, client framework, and of course language. You write your first few lines of code, simple and weak, using the same basic patterns that you read in the “Getting Started in X Web Framework” tutorial. As you grow in expirience, reading more Stack Overflow answers you begin to use more refined tools to accomplish the same tasks in ways you’d label “better architected” or “more scalable”. In the “middle” portion of this new webapp when you hit Minimum Viable Product is probably the highlight of the webapp: You’re progressing at a very notable pace, you frequently add new features and upgrades to existing ones, and the sense of accomplishment is very high. As you start to near completion where all of the features have been implemented the “newness” begins to wear off: You’re only refining existing features now, making small slight changes and tweaks here and there. The only progression left begins to render very small changes. A 0.5% improvement here, a 0.75% iimprovement there. The time between “upgrades” becomes farther and father apart as more people begin to use your webapp and you risk upsetting people’s workflow by changing too much. The excitement and passion is slowly draining.

At this point what happens? Well in an RPG you’d either re-roll a new character or switch to another game. In webapp development you’d either “re-roll” the projects by re-writing huge portions of it in the latest language or framework. Or you’d switch to another “game” (a different project).

I think this is somewhat of a problem but I’m not sure what the fix is. Is there a way to keep excitement, newness, and a sense of accomplishment on a well establish project? If so how?

Blekko & Google: A Quick Study in Color Contrast

Tue, 02 Nov 2010 18:34:00 -0600

Blekko recently launched with much fanfare. There hasn’t been much change in the search engine world recently so I imagine a flood of early adopters will give them a steady flow of traffic for sometime. Being a techy and web developer myself I of course wanted to hop on the bandwagon early on.

However within just the first day I began to feel like Blekko was “harder” to use. That sounds silly right — it looks and works almost identical to Google. I couldn’t quite put my finger on it but the search results page felt undecipherable if I was just scanning it. With Blekko search results I felt forced to read each result individually.

So curious I compared Google and Blekko side by side.

They look almost identical: Blekko is red, Google is blue. How hard can it be?

But after further use what I began to notice was that I had a harder time scanning the titles of the search results. Apparently over the years I’ve developed a habit of just scanning the titles and completely skipping the summary, unless of course the title is of interest.

When it comes to Blekko, this is how it feels to me…

The interesting thing is that I think this is simply an issue of the contrast relationship between the title and the tools/links under it.

Here’s an example of what I mean. If everything was to remain constant except the links below the title, the ability to scan the result titles becomes increasingly easier.

Try scanning these two and quickly reading just the titles. Which is more comfortable on your eyes?

Is the Golden Age of Django Over? [Opinion]

Mon, 01 Nov 2010 19:54:00 -0600

To me Django was revolutionary. Sure there were many more frameworks who came before it, but for those of us who didn’t care for the scaffolding-command-line-driven style Ruby On Rails offered, Django was a breath of fresh air to the otherwise tedious task of web development. Django had so much going for it…

Tons of features
Built on python
A positive and helpful community
Good documentation
Very easy-to-use ORM
and so on

I spent about a year and a half learning and using Django, enough so to earn the Django Badge and be in the top 20 answerers for the django tag on StackOverflow.

Aside from the general technical benefits that Django brought to many, it was personally quite revolutionary for me. A brief bit of history here if you would entertain me.

A few years ago I was in an interesting point in my career where I really needed to start seriously pursuing if I wanted to be a web developer/user interface guy or if I wanted to be a graphic designer/marketer. My web development career had initially kicked off with classic ASP and various ill designed apps which naturally led to .NET and C#. However my day job was largely design and marketing.

Those were the days web development was weary work. Some still used HTML tables because CSS layouts were slightly broken in a handful of browsers. AJAX was just starting to become buzz-y and the phrase “web two point oh” was being incubated in journalists minds.

I had found that the majority of my web development tasks were concentrated on boilerplate and infrastructure. I considered a future in such monotony wasn’t looking enjoyable and was questioning my web development role.

Unknowing to myself I had actually created a mini-web framework very similar to Django in C# for .NET. I had all the things you’d expect: a templating engine, an HTML forms engine, and a data layer that abstracted a decent portion of the underlying SQL away. I spent most of my time trying to keep this up and it really slowed real progress on the website I was working on.

Humorously, it was actually the announcement of ASP.NET MVC that lead me to Django. You see after learning the general principals of MVC I realized something I should have already known: The entire internet was trying to deal with these same issues. I’m sure it surprised others too. It’s a lesson you don’t learn in school. Shortly there after that I set out to find a language which provided a vast array of libraries that I could use to free up development time to actually focus on domain problems and not supporting thousands of lines of libraries.

This lead me to Python — And who was the knock-out web framework for Python at the time? None other than Django. Some called it “Python’s answer to Rails”. This was back before Django and pink ponies were synonymous.

I learned Django in 2 days (went through every chapter in the Django Book) and was just totally blown away. For the next year and a half everything I did web-related was in Django, including a rather large website and a handful of Django reusable apps.

In a sense Django was my training wheels to thinking about web development in an abstract, separated, and well defined way. Django didn’t just team me MVC — it got me thinking about how websites are architected. Once I realized there was an entire ecosystem of web application frameworks I was like a kid in a candy story; Pylons, Werkzeug, Sinatra, Merb, Seaside, Lift, Flask, and most recently Tornado. I wanted to learn them all.

In my eyes Django was revolutionary, but it wasn’t without it’s issues — most of which I could happily overlook. It seems though that in the wake of Django’s success literally hundreds of web app frameworks, many written in Python, have followed offering potential developers a certain take on how web development should be done.

Receiving a slight bit of internet buzz recently, Alex Martelli recently recommended Flask (based on Werkzeug) over Django for personal projects.

Today it seems there is such a choice of frameworks that it’s highly unlikely that one would not find something they like which is specialized to their development style or project. However in the jungle of choice I’m wondering [out loud] if Django is being left behind as the large-one-size-fits-all that no one feels fits them like more specialized frameworks do.

In some sense we knew it was coming; no technology lasts forever. In another sense it seems like Django’s time in the spotlight was too short lived. Was it that Django included so much (batteries included) and the web changes so fast that it can’t keep up? Is it that Django’s broad focus lends itself only to projects that fit it specifically? Is it that the technical innovation of “competing” frameworks give developers enough of an edge for them to switch? Is it just that developers have an insatiable appetite to use the latest and greatest, even if the previous worked just fine?

Is the Golden Age of Django over?

Why Using the AJAX Spinny Wheel Is Bad [Opinion]

Thu, 28 Oct 2010 20:52:07 -0600

Alright that was a tricky title just to get you to read the first line.

Twelves years ago when I made my first website on AOL’s “MyPlace” I copied some javascript I found out there on the internet somewhere to try and make a hover effect for my “personal webpage”.

Why? Because it looked cool.

A few years later I was implementing DHTML page transitions.

Why? Because it looked cool.

A few months ago I was sticking that stupid AJAX spinny wheel on everything.

Why? Because it looked cool.

Just like javascript hover effects and DHTML page transitions maybe it’s time to stop and think about what we’re doing with AJAX. To be fair the actual AJAX spinny wheel itself isn’t bad in and of itself. Giving visual feedback to the user to indicate something is happening is always a good choice.

However I’ve started to notice that whenever I find myself reaching for the AJAX spinny wheel I need to really take a long and hard look at what I’m doing. In the majority of cases the AJAX spinny wheel indicates that I am replicating browser functionality.

Unless there is really a specific benefit that can be gained by doing this it almost always ends up bad. In the past few months I’ve actually had a couple of projects I was working on where the interface had been written in AJAX and I ended up un-ajaxifying the UI because not only did the AJAX UI not add value but it was restrictive and removed default browser functionality.

AJAX often brings problems like…

Non-standard interfaces and interface elements
Reduced browser default functionality* (history, back/forward buttons, etc.)
Unnecessary lag via animation effects often implemented to display AJAX content changes
Reduced SEO*

* - Yes I know there are efforts on these fronts to improve this, but still.

The fact still remains that the majority of times end users would rather have a predictable, usable, and effective website experience than to have a glittery, effects-filled one.

It’s sad. I know. I just re-read that to myself and it was more sad the second time. Being half designer this pains me even more.

Eric Ries (on the topics of A/B testing websites) says it well: “…this led us to confront the disappointing reality that sometimes customers actually prefer an uglier design to a pretty one…”
[The one line split-test, or how to A/B all the time, Sep 15, 2008].

The next time you reach for the AJAX spinny wheel ask if you’re really adding efficiency to your webapp or if you’re just sprinkling unnecessary glitter.

3 Cool Jquery Tricks I've Been Using Lately

Tue, 14 Sep 2010 10:00:00 -0600

Everyone loves jQuery. Ok maybe not everyone, but at least a huge portion of the internet. It’s likely because jQuery implements the DOM very similar to how it should have been implemented in the first place (but we won’t beat that dead LiveScript horse anymore).

Anyways, here are some cool tricks that I’ve learned, used, or been using lately…

1. Use .live for binding events on elements not yet created

It’s common to write jQuery code that creates new DOM elements or shuffles them around. What’s not cool is to try to wire-up events up to those new or shuffled elements, especially when you don’t know if they’ve previously had event handlers attached to them. I often found myself doing things like this…

var bindTagEvents = function(tag) {
    $(tag).unbind().click(function(){
       // foo 
    });
}

// ...

span = $('').attr('title','My New Span');
$('body').append(span);
bindTagEvents(span);

Note the unbind() before the click(). Yeah it works, but jQuery provides the .live function which works for all elements current and future. This means even if we were to create that new span tag and append it to the <body> tag, the .live function would still apply it. Using .live, we can shorten the example above down to…

$('body > span').live('click', function() {
    // foo
});

// ...

span = $('').attr('title','My New Span');
$('body').append(span);

2. Draw attention to newly created elements using the highlight effect

Again it’s common to create new elements in our jQuery scripts but one thing to be concerned with is how it will feel to the user. Often times the addition of new content is subtle enough that users won’t notice, even if we the developers do.

JQuery UI provides an effect known as “Highlight” which when fired causes the element to briefly pulse in a yellow “highlighter” color, hopefully drawing attention to it.

Implementing it is ridiculously easy:

$(tag).effect('highlight', {}, 1500);

The 3rd argument is the length — in milliseconds — that the yellow highlight color should fade out with. It sounds like an obnoxious effect but it provides a subtle visual cue for users that a new element has been created.

3. jQuery Includes an Auto-Complete Feature

No kidding. Like the highlight effect mentioned above, this feature requires the jquery-ui library, not just jquery ala-carte. To be fair, there are many autocomplete implementations that have more features, but if jquery-ui is already included on your page why add another dependency (unless of course you really need that killer feature).

Autocomplete takes a couple of properties and handles most of the plumbing of what it takes to make an autocomplete/autosuggest system. When activated on an input:text, the only thing it really needs is a datasource.

// Any array will do...
$('input').autocomplete({
    source: ['batman', 'robin', 'joker', 'catwoman', 'dr. freeze', 'penguin']
});

// Or URL of a custom page that returns an array in JSON format...
$('input').autocomplete({
    source: 'yoursite.com/api/autocomplete'
});

// Or a callback (to implement basic caching perhaps)...
var $autoCompleteCache = {};
$('input').autocomplete({
    source: function(query, addOptions) {
        if ($autoCompleteCache.hasOwnProperty(query)) {
            addOptions($autoCompleteCache[query]);
            return;
        }
        else {
            $.getJSON(
                'yoursite.com/api/autocomplete',
                function(data) {
                    $autoCompleteCache[query] = data;
                    addOptions(data);
                }
            )
        }
    }
});

Bookmarks Are Dead

Mon, 13 Sep 2010 22:40:00 -0600

At least to me. I noticed the other day that I almost never use bookmarks anymore. A year or two ago I was a bookmark junky, having 500+ easily. So what changed? In reflecting upon it, I think there are a few reasons for this…

I switched to using Chrome whenever I’m not doing web development (Firebug is just too awesome to give up). The way Chrome is designed the bookmarks aren’t exactly a prime, in-your-face feature which are easily accessible — at least not in the way Firefox and Internet Explorer implement it.
I use Twitter much more than I did in past years. A lot (and by lot I’d say 50% at least) of the new sites I visit are from links seen on Twitter. I follow people who tweet about topics I’m interested in (@smashingmag, @sixrevisions, @activestate, @cssbeauty, @usejquery) and thus click a lot of links that are posted.
Instead of “surfing the web” looking for new sites, as was all the rage in the 90’s, I tend to frequent the same sites, often times which serve in some part as content aggregation — and I already know their address. Why do I need to bookmark it?
Chrome Pinned Tabs — Sites I really frequent have a permanent Chrome tab to keep them open.
Chrome Address Bar — Why waste the time to find a bookmark when you can just type something relatively close to what you want into the address bar and get instant results?

(Why are 3 of the 5 related to Chrome? Google conspiracy theories ignite…)

5 Reasons to Consider Tornado for AppEngine (Python)

Thu, 09 Sep 2010 21:42:00 -0600

As I’ve begun to become better acquainted with Google’s AppEngine platform, I’ve hit a few points where the python-based “webapp” framework is less than desirable.

While I have a background in Django, I didn’t feel as if it was a fit for AppEngine due to it’s heavy data layer ties. On the flip side, Tornado (IMHO) is a lightweight alternative and prime candidate.

Tornado, if you don’t know, is the web framework that powers FriendFeed and was recently open sourced by Facebook. It includes the basics you’d expect: request handling, routing, templating; you know, the usual fare. A scatter of MySQL utilities come bundled, but the framework leaves the data layer completely up to you (consequently it doesn’t including features like an automatic administrative interface or data models-to-web forms).

1. May the Source Be With You

Sure, webapp has online documentation, but sometimes it’s easier to just read the source. Even better, in Tornado’s case it’s available via GitHub.

Depending on your experience with python this might not sound like a compelling reason but consider this: You will likely have the tornado source folder inside of your project’s folder while developing (as it needs to be deployed to AppEngine with the rest of your python source files). This means you can simply open up the Tornado source files in another tab in your editor for quick reference.

Once you get used to doing this it greatly speeds up your development time when you need to reference something and it gets you much more acquainted with how the framework works.

2. Simple Templating

There are quite a few good templating engines out there for python. The problem I have with many of them is that they typically are too complicated or unnatural in syntax or too restrictive for in form, particularly when it comes to creating re-usable sub-templates which manage their own logic and data independent of the main page (I’m referring to what Django and other engines call “template tags”).

Before I mention tags a few words about the Tornado template engine — it’s simple. It uses the common {% %} format. It lets you put real python in between the {% %}’s Sure, people say logic should be out of the template, however if it’s logic that relates to display I disagree. Tornado gives you the choice. If you want it, use it. If not, do it the hard way. It’s up to you.

Behind the scenes Tornado compiles the templates to a python file to make them speedy when serving to viewers (this has the odd side effect of requiring you to restart the appengine dev server whenever you change the template).

The one slip up is that if you, like me, are used to Django-style templates, you’ll probably write things like “{% endblock %}” or “{% endif %}”. Tornado simply uses “{% end %}” for everything.

3. Drop-Dead Easy Template Tags

So about template tags, Tornado refers to them as “UI modules”. Defining a new module is dead simple…

class SchemePreviewSmall(BaseUIModule):
    def render(self, scheme, lang='python'):
        data = self.handler.data.get_something_cool(scheme)
        return self.render_string('modules/scheme-preview-small.html',
                                  scheme=data,
                                  lang=lang)

In this example I’m calling the method get_something_cool which is actually a member of the calling RequestHandler (self.handler). The return value is then used to generate the response by loading and rendering a template. The nice thing here is that if I have a re-usable widget such as an ad, a login interface, whatever I can make it a module and re-use it throughout the site.

Using this module in a template is as easy as…

{{ modules.SchemePreviewSmall(scheme) }}

4. Easy to follow documentation

Yes, if the source isn’t you thing, there still is easy-to-follow documentation. There’s enough there to get you up and running in an evening and you’ll learn a lot of cool tricks too.

5. Minimal to Convert

Lastly, the webapp and Tornado syntax for request handlers are so similar, converting to Tornado from webapp requires minimal effort.

webapp Request Handler

class HelloWorld(webapp.RequestHandler):
    def get(self):
        self.write("Hello World")

Tornado Request Handler

class HelloWorld(tornado.web.RequestHandler):
    def get(self):
        self.write("Hello World")

There are, of course, a few other differences. For example, fetching the value of a querystring. Webapp uses self.request.get() while Tornado instead does self.get_argument(). The differences are minor and easily done with Find and Replace.

Restoring Browser Functions to Clickable DIVs Without Javascript

Fri, 20 Aug 2010 10:44:00 -0600

Occasionally the situation comes up in web development where you have a highly styled tag such as
<div> or <li> that you want to make clickable. This often happens when you have a list of items in which you want to make the entire item clickble instead of just the title for example. The standard fare for doing so is to set { cursor: pointer; } with CSS then to bind the .click event to the tag (in jQuery as so)….

$('#myDivTag').click(function() {
    // your code here
});

Don’t get me wrong — this does work. However, in doing this what you loose is the standard functionality that most viewers are used to; things like middle clicking to open in a new tab, right-click to copy URL address, and so on. There is also the lag between when the page renders visibly to the user but the javascript hasn’t downloaded and $(document).ready hasn’t yet fired. In this case the tag will not be clickable but the mouse cursor will indicate that it should be.

I’ve been dealing with this more so lately and there are a couple of ways to solve this problem.

The first is to wrap the <div> (or li or whatever else) tag in an anchor tag <a> and set that anchor tag to { display: block; }.

<style type="text/css">
	#myDivWrapper { display: block; }
	#myDiv {  }
</style>

<a id="myDivWrapper">
	<div id="myDiv">
	       ... content ...
	</div>
</a>

By wrapping the div tag in an anchor you’ve restored the default functionality viewers are used to with a clickable item. This works in most browsers but for the most part things like <div> and <li> are not allowed inside of an anchor tag per HTML language specifications. In a sense in doing something like this you are rolling the dice that the next version of IE9 strict mode won’t render when it hits this.

It also feels kind of weird, because all of the styling that was on #myDiv, things like height, width, float, etc., now need to be applied to the anchor tag instead. And no one likes wrappers. They just clutter things up.

The 2nd way to solve this problem which I’ve started using lately is to have an absolutely positioned anchor overlay the area of the div. Consider the following…

<style type="text/css">
    #myDiv { position: relative; }
    a.clickable-overlay {
        position: absolute;
        top: 0;
        left: 0;
        height: 100%;
        width: 100%;
        z-index: 1;
        display: block;
        background-color: transparent;
    }
</style>

<div id="myDiv">
    ... content ...
    <a class="clickable-overlay" href="#wherever"></a>
</div>

Here’s what’s happening: At the end of the <div> (or li or whatever) we’re adding an anchor tag. The parent div is set to { position: relative }, and the anchor tag to { position: absolute; }. If you’re not familiar with position absolute you’re missing out. The way it is designed to work is that any element positioned absolutely is done so in relation to it’s parent (or any parent’s parent) that is positioned either relatively or absolutely. What this means is that in setting our <div> tag to position: relative the anchor tag with position absolute will be positioned relative to the div. Top 0 and left 0 will be the top left of the div, and height 100%, width 100% will cause the anchor to fill out the area of the div.

The result is that we are left with a transparent anchor tag that completely overlays the area of the div, providing the default clickable behavior users expect. The last CSS trick to making this work is to set z-index to 1, forcing the browser to always render the anchor tag over whatever content is in the div.

The positives to this method are that 1. we restore the expected clickable behavior without javascript (meaning it also works as soon as that markup is rendered and not when $(document).ready is fired) and 2. we’re using correct HTML syntax.

I should point out there is a downside to this method, in that because the anchor overlays the div, the contents of the div are no longer selectable or clickable. Depending on your application this may be negligible.

Top 10 Programming T-Shirts That Don't Make Sense

Thu, 12 Aug 2010 21:27:00 -0600

mind.location = unknown
http://www.zazzle.com/javascript_mind_tshirt-235892961444457742
I wonder what the value of the variable unknown is?

import_soul
http://www.zazzle.com/import_soul_tshirt-235715645595867505

What is import_soul? It’s written as a keyword. If it were a function it should be import_soul(), however the keywords for this shirt include “python” which makes me thinking they meant import soul.

Function Check_Drunk()

http://www.zazzle.com/function_check_drunk_tshirt-235954739548677347

Where do I begin with this one… drink is treated as a global variable but never declared globally. Then there’s the awesome conditional if “bra = true” which will always return true because a single = is assignment not evaluation. Lastly, none of the functions are ever called, they’re just declarations of.

Programmers Cool Club

http://www.zazzle.com/cool_programmers_club_tshirt-235068746346060145

No comment needed.

.ninja { color: black; }

http://www.zazzle.com/css_ninja_style_class_tshirt-235091799113607617

This one’s amusing and almost worth getting, but the behavior of visibility: hidden; is such that it keeps screen space allocated for the element and simply does not render it. I personally believe a true ninja would { display: none; }.

Geek Power

http://www.zazzle.com/geek_power_tshirt-235232870665206831

No geek would ever intentionally rip the cord to their keyboard like that

Computers are Only Human

http://www.zazzle.com/computers_are_only_human_tshirt-235670270460766159

Apparently I didn’t get that memo.

SELECT TOP 25

http://www.zazzle.com/the_best_sql_query_ever_tshirt-235031072069340726

Aside from using the vendor-specific “TOP 25” (MS SQL), the comment at the bottom brings to light the poor execution of this SQL: It should be sorted DESCENDING

Do You Speak Code

http://www.zazzle.com/do_you_speak_code_tshirt-235290525576102199

There’s No Crying in Programming

http://www.zazzle.com/no_crying_in_programming_card-137314447034339159

Python Templating For the Web (Random Ideas)

Sat, 07 Aug 2010 00:20:00 -0600

Well it’s past midnight and I’m musing about web templating in Python for Tornado or AppEngine. The thing about most Python templating engines that I notice is…

There’s kind of an obsession with being agnostic about everything. You can render JSON and XML and whatever else you want with our engine! When is someone just going to make a really awesome templating engine for the web and not try to be everything to everyone?
The value in a template engine to me is how easy it is to allow the template to include logic that’s independent of the controller that’s generating it. For example, you might want a server-side ad manager on every page, but you don’t necessarily want to put the code for that in every controller. Solution? Some engines call it modules, some call it template tags, but whatever the name there is some type of logic that’s independent of the controller. The problem is that most of these pieces of independent logic are needlessly complicated. (side note: Django has gotten a bit better about this since I first used it two years ago).
Maybe some better support for lazy-loaded values which are available for all templates… things like static URL, etc.

So it’s late and I’m thinking, what if there was a template engine, and I mean one specifically for the web, which represented an HTML document more so as a Python class. Every root element or element with an ID is a property of the document. Tags can interact with each other… Maybe this is turning out to be too much of a DOM implementation in Python. Maybe this is a bad idea. Or maybe I should try coding up a prototype just to see what it’s like.

But it’s not quite a DOM. The DOM is concerned with specific structure, where as we’re only concerned with a loose abstract structure. It doesn’t matter of the area where scripts are printed too is in the or right above , what’s important is that there is a scripts area which sub-modules can access.

Instead of {% extends “some_html_file.html %}, it could be {% extends templates.master %} where templates.master is a python module.

(15 minutes later)… you know it kind of sounds like I’m trying to re-invent ASP.NET WebForms…