another "minor" release in the 1.4.x line -- read the blog for more details: http://blog.jquery.com/2010/10/16/jquery-143-released/

it's got some cool stuff in it, and shows to me that the jQuery team has their shit together in a huge way. They call a release like this minor, where a lot of development teams would consider that much work a substantial release. In any case, I don't normally bother to write about release updates, but there's something pretty juicy in this one relating indirectly to templating via a small change in the .data() methods. 

first imagine a template like:

<div id="user" data-id="1" data-name="John">
Hi  {{name}}
</div>

previously you had to monkey about doing things like var id = $('#user").attr('data-id'); to get that id and pass it to your templating engine. if you were passing several bits of data this could be tedious so you probably improved the above template to look like this:

<div id="user" data-user="{ id: '1', name:'john'}">
Hi  {{name}}
</div>

allowing you to pull all your attributes in one object, but you still had to manually pull your attributes all the time. 

enter 1.4.3 and all html 5 data attributes (you have been using the data-xxx format right?) are automagically read into the elements .data() object. this seems minor but is going to save a lot of tedious work because if the above template is used now you can just call $('#user').data('user'); and have access to all those values right out of the gate. 

sometimes small intuitive changes have the biggest impact. 

I can immediately go through some code on the app i'm working on and trim out a bunch of .attr() calls saving me code. but more interestingly anywhere i've already been using the html5 data tags (and i have) i already have access to those as data if i need them and this is key for me. It encourages the proper use of a new standard (html5) and rewards you for adopting it early with less work. We need more improvements in our tools along this line because it's the quickest way to get new standards to be "the" standard. 

when you couple changes like the above with speed improvements and implementation improvements (like becoming more compatible with CommonJS) and changes borne from your user bases expectations (Calling .data(Object) no longer completely replaces the data object instead it extends the existing object, leaving the unspecified values in place) you get a really great project to work with, even for minor releases. 

Permalink | Leave a comment  »

i've long thought the real battle of becoming a great programmer comes in ingesting the right concepts. most programmers are pretty clever and once they grok something in a way that makes sense to them theres a moment of clarity and inspiration that comes from seeing all the interesting ways you they could apply this new idea. this process is the heart of programmer growth. Ignoring the cruft, those programmers who treat programming as a job, it's clear the real impediment to growth is getting the right conceptual explanation (through books, tutorials, play, experiments, blogs, et al). When we have the right conceptual model, complex ideas become simple and practical. your conceptual model is the expression of your understanding of the things you're working with and determines what calibre of programmer you're going to become. 

Interestingly, most top programmers rely on code to explain themselves because articulating their latent conceptual framework is either impossible, or the outline of it is so deeply stacked on other concepts it's like explaining the evolution of western philosophy. This conceptual stack problem is hard to get around. You can't accurately explain many sophisticated concepts without leaning on an underlying stack of other sophisticated concepts. Imagine giving Javascript: the good parts to a very junior programmer. They don't have a the basic concepts upon which much of the book relies and would get little from it. 

to that end, I've been thinking about a series of conceptual posts trying to boil an idea down to it's simplest conceptual explanation--which, im learning is often harder than the code itself to come up with. Lets give this a try with the oft misunderstood, but incredible helpful jQuery.delegate function. 

The existing concept:

from the api docs: http://api.jquery.com/delegate/

Delegate is an alternative to using the .live() method, allowing for each binding of event delegation to specific DOM elements. 

.delegate( selector, eventType, handler )

selectorA selector to filter the elements that trigger the event.

eventTypeA string containing one or more space-separated JavaScript event types, such as "click" or "keydown," or custom event names.

handlerA function to execute at the time the event is triggered.

$("table").delegate("td", "hover", function(){
        $(this).toggleClass("hover");
})

the above snippet will listen for hover events against "table" and fire the enclosed code when they happen. super clear right?

A new  concept:

jQuery.delegate is all about efficiency. I'm going to use the concept of a teacher and a classroom of students to lay this out in simple terms. Lets start by imagining a theres a teacher in a classroom that needs to know when each student is done their tests. Theres two ways to approach this:

1. give each student individual instructions, one a time, to come tell the teacher when they're done.
2. put instruction on the board for the everyone in the class telling them to come up and tell the teacher when they're done.

which is more efficient and flexible? in the first scenario what happens if another student comes into the room (perhaps by ajax :P) to take the test after the instructions have been given individually? and what happens if we change our minds about what the student needs to do when the test is done? do we have to go back and individually explain the new instructions?

lets try this as a bit of code:

$("classroom").delegate("student", "doneTheTest", function(){
        $(this).tellTheTeacher();  //$(this) == the student thats done right now
})

Permalink | Leave a comment  »

i'm off work right now. I quit my day job a couple weeks ago and i'm back to contracting. I've committed to a project but we're not underway yet so I continue to play with nodejs and evaluate the development stack i work in. my current default stack is extjs/jquery->symfony->php/mysql->LAMP but my goal is to move towards nosql (mongodb) and more fully into javascript. to that end today i'm playing with javascript mvc.

the model of jmvc is not entirely clear to me (where it fits in the stack, how it relates to the various parts of an app's life cycle) but heres what i've figured out so far that isn't explained on their site:

note: i'm running windows7. I have a number of ubuntu VM's i could have easily used for this but i didn't. i've also downloaded and compiled raff's nodejs for windows, you should do the same. node on windows is sexy.

things to grok right away:

jmvc relies heavily on a command line code generator which relies heavily on java and rhino. two things i know little about but i do know if you go to your command prompt and type java -version and don't get a version spit back at you you're not going much further till you add the path to your java install ( likely C:\Program Files (x86)\Java\jre6\bin) to your system environment variables path variable. google how to do that.

once you have that badboy in place you can download and extract jmvc to a folder somewhere on your hard drive. add a file called app.js to the root folder you just created and put the following code in it:

var sys = require("sys"),
    http = require("http"),
    url = require("url"),
    path = require("path"),
    fs = require("fs");

http.createServer(function(request, response) {
    var uri = url.parse(request.url).pathname;
    var filename = path.join(process.cwd(), uri);
    path.exists(filename, function(exists) {
        if(!exists) {
            response.sendHeader(404, {"Content-Type": "text/plain"});
            response.write("404 Not Found\n");
            response.close();
            return;
        }

        fs.readFile(filename, "binary", function(err, file) {
            if(err) {
                response.sendHeader(500, {"Content-Type": "text/plain"});
                response.write(err + "\n");
                response.close();
                return;
            }

            response.sendHeader(200);
            response.write(file, "binary");
            response.close();
        });
    });
}).listen(8080);

sys.puts("Server running at http://localhost:8080/");

now open up your cygwin bash console and cd to the folder we were just working in.

type node app.js

presto. you've just created a node static server around that folder and you can browse to http://localhost:8080/index.html to see the default page that comes with jmvc. from there you should be able to follow the tutorials on the website and learn some extra jmvc goodness without resorting to iis, or some convoluted apache install on windows.

5 mins to a nodejs static file server + jmvc install.

Permalink | Leave a comment  »