Profile cover photo
Profile photo
tadeu dev
tadeu's posts

Post has attachment

Post has attachment

Post has shared content
jQuery 1.7 beta sneak preview

Hey guys. This is a preview of a segment I wrote for the jQuery blog that might get pushed a little later in the week when the release moves to beta. I'm posting it here in case there are any questions or comments that pop up that we haven't covered just yet. Let us know if so. Enjoy!.


Long-time jQuery contributors Dave, Rick, Corey, Jon Neal, Timmy and a handful of other enthusiastic developers have been hard at work this week landing a number of new features into jQuery core. The project is currently preparing for a rollout of version 1.7 of the library sometime during early October but today you can get a sneak peek of what's to come.

Whilst patches and other commits are still being landed, I thought it would be interesting to take you through some of the new features you can expect to see in jQuery 1.7 through examples based on our unit tests - accompanied with explanations of what they have to offer and some extra comments.

All of these can be played around with using our up-to-the minute version of jQuery (git or 'edge' as it's called on and should be cross-browser compatible.

Remember, if you happen to come across any quirks or bugs with these features, we'd appreciate it greatly if you could report bugs with them through our official bug tracker:

Support for registering jQuery as a CommonJS Async Module

The first feature to land that I've been quite excited about has been support for registering jQuery as a CommonJS-compatible asynchronous module. This is something that wouldn't have been possible without the dedication of RequireJS author James Burke, who was responsible for much of the work that went into the commit.

There are a number of browser-based CommonJS-compatible script loaders (including RequireJS) which are capable of loading modules using an asynchronous module format. With this commit, jQuery now also registers itself using the format so it's able to take part in browser modules loading using any compatible loaders.

You may be curious as to why this is important.

Due to jQuery's popularity, AMD loaders need to take into account multiple versions of the library being loaded into the same page as you ideally don't want several different versions loading at the same time. Loaders have the option of either specifically taking this issue into account or instructing their users that there are known issues with their use and the library.

What James' addition brings to the table is that it helps avoid issues with other third party code on a page accidentally loading up a version of jQuery on the page that the page owner wasn't expecting. You don't want other instances clobbering your own and so this can be of benefit.

The way this works is that the script loader would indicate that it supports multiple jQuery versions by specifying that a property, define.amd.jQuery = true. For those interested in more specific implementation details, we register jQuery as a named module as there is a risk that it can be concatenated with other files which may use 'define', but not use a proper concat script that understands anonymous AMD module defintiions.

The named AMD provides a safety blanket of being both robust and safe for most use-cases.

// Account for the existance of more than one global instances of jQuery in the document, cater for testing .noConflict()
var jQuery = this.jQuery || "jQuery",
$ = this.$ || "$",
originaljQuery = jQuery,
original$ = $,

// This is a mock AMD define function for testing AMD registration, but could easily
// be replaced with one of define variations from the wild.
function define(name, dependencies, callback) {
amdDefined = callback();

// The very easy to implement flag stating support which would be used by the AMD
// loader
define.amd = {
jQuery: true

console.log(jQuery, amdDefined); //notice both instances are equivalent

Improved Support For HTML5 With jQuery

jQuery 1.7 won't come with it's own built-in HTML5 shivs (you'll still have to load in a shiv of choice into the document head), but it will address two important issues previous releases have suffered:

1) In jQuery 1.6.4 and below, HTML5 elements were not supported with innerHTML but this is rectified with the newest release. HTML5 elements now added with any methods using innerHTML under the hood are added to a successfully shim'd document or document fragment as one would expect.

2) HTML5 elements being cloned (when an element is cloneNode'd) will now use an alternative approach to cloning which supports cloning HTML5 elements cross browser.

// here's an example of a html5 shiv that would be loaded in the head of your document
// you can of course alternative between the solutions used for this
( "abbr article aside audio canvas details figcaption figure footer header hgroup " +
"mark meter nav output progress section subline summary time video"
).replace(/\w+/g, function(n) {

// let's append some HTML5 elements which will be inserted internally via innerHTML. This
// should now work fine with all browsers, assuming a HTML5 shim/shiv is being used
$("#el").append("<article style='font-size:15px'><section><aside>HTML5 elements</aside></section></article>");

// selection of HTML5 elements we added above
var article = $("article"),
aside = $("aside");

// simple tests to ensure that the HTML5 elements are valid and can be styled via jQuery
console.log( article.css("fontSize"), "15px", 'HTML5 elements can be styled');
console.log( aside.length, 1, 'HTML5 elements don't collapse their children')

Support for named queues that can be used by .animate()

In previous releases, .animate() supported queues - a feature which allowed a sequence of actions to be called on elements asynchronously without blocking application execution. In jQuery 1.7, Corey suggested adding support for queue names - a string which when supplied would queue animations based on queue names in a specific order. This is extremely useful for getting a more granular level of control over your animation sequencing.

Note how in the example below, each queue can be assigned a string representing an identifier (i.e the name). As confirmed by the 'order' array being updated, the order of callback execution experienced is preserved as desired because all queues are being defined under the same identifier.

// For this particular example, the first callback function for the test is called via a // setTimeout() at the end just for the sake of demonstrating dequeuing. You can of course // just stick to queues within your original animation chain for most common needs.

// select an existing element for usage
var foo = $( "#foobar" ),
origWidth = foo.width(),
order = []; // here just for testing purposes

// animate with a named queue and some standard animation properties
foo.animate( { width: origWidth + 100 }, {
queue: 'name',
duration: 1800,
complete: function() {

// our second callback function

// push the order number into the stack so we
// test execution order was as expected
order.push( 2 );
console.log('second callback', order);

}).queue( "name", function( next ) {

// last callback function
console.log('last callback',order);

setTimeout( function() {
// this is the first callback function that should be called
order.push( 1 );
console.log('first callback',order);

foo.dequeue( "name" );
}, 100 );

Support for removing multiple attributes with removeAttr

Another minor, but interesting feature that was also added was the ability to remove multiple attributes from an element using .remoteAttr(). Previously this method only allowed single attributes to be removed, but this has now been expanded to support space-separated attribute removal as demonstrated in the example below:

// create an element with a number of sample attributes we can test
var div = $("<div id='a' alt='b' title='c' rel='d'></div>"),
tests = {
id: "a",
alt: "b",
title: "c",
rel: "d"

// check to make sure that all attributes have been assigned correctly and exist with their
// expected values
$.each( tests, function( key, val ) {
console.log( div.attr(key), val, "Attribute `" + key + "` exists, and has a value of `" + val + "`" );

// remove these attributes
div.removeAttr( "id alt title rel" );

// check to ensure these attributes are no longer present
$.each( tests, function( key, val ) {
console.log( div.attr(key), undefined, "Attribute `" + key + "` was removed" );

Support disabling scanning the data cache for attributes multiple times

Quite a few developers use in their projects for storing arbitrary data associated with an element. Beneath the hood, however, whenever you make more than a single call to .data(), you actually end up having to loop over all of the attributes for the element looking for 'data-' attributes each time you access it. With 1.7, we've introduced an optimization which avoids this, meaning that applications making heavy use of .data() will have to do just a little less work than previous versions.

//Here's a jsPerf performance test of the optimizations thanks to Corey

var testing = {
test: "testing",
test2: "testing"
element = jQuery( "<div data-test='testing'>" ),
node = element[ 0 ];

// assign some data-attributes to our node for testing
node.setAttribute( "data-test2", "testing" );

// ensure that the data we've set is actually present - minor sanity check
console.log(, testing, "Sanity Check" );

// assign some more data-attributes
node.setAttribute( "data-test3", "testing" );

// check if .data() has changed as the data-* attributes have
console.log(, testing, "The data didn't change even though the data-* attrs did" );

// clean up data cache


That's it for this preview. I hope you enjoyed it. These features are only a fraction of what's landed so far for 1.7, but if you're interested in keeping up with changes as they get made, feel free to checkout jQuery on GitHub. We also have a twitter account that gets updated on each commit over at @jquerycommits for anyone that prefers that route.

Until next time, happy coding!.

Post has shared content
Context: in early 2009 or so I wanted to see what my life would be like if I unfriended everyone who wasn't a relative on Facebook. I found it socially suffocating for a week or two, then I got used to texting, IMing and emailing good friends instead of relying on Facebook to keep them up to date and vice versa. I only very recently added friends I see in real life back. It's hovering around 100 people. At my max I had something like 700 or so, 600 of which I barely knew.

The bit about work points to the fact that when you have lots of "downtime" at work (XKCD: compiling), you tend to go on Facebook, and you tend to have more time to find funny things to share. I very rarely went on Facebook at home since I was tired and just wanted to relax. I suspect everyone else in my connections can describe a similar experience.

One thing is for certain: I find Facebook to be boring as hell now. With hundreds of friends, there's always something happening and a huge matrix of possible interactions in your news feed. You can post a picture of your lunch and get a potentially interesting discussion. When you're connected to just the people you already talk to regularly, there isn't a ton of stuff that gets posted or shared that you haven't already gotten straight from the source. Usually, your friends who DO have a massive friend count censor themselves to the point of being downright uninteresting.

Post has attachment

Post has shared content
Como linkedin usa o node.js e html5 para construir melhor e mais rápido suas apps!
I'm actually pretty amazed at how good the new LinkedIn Android app looks. +Lucian Beebe once made a comment about how all he saw in his Stream on Google+ were posts by Googlers; that's funny, because the majority of what I see on my home feed in LinkedIn are posts from LinkedIn employees, too. Oh, and Twitter spam ($@Y*%*). They really need to undo the Twitter integration in the home stream or make it optional (+Nick Dellamaggiore, some love here?).

I'm not surprised node.js outperforms Ruby on Rails, but let's be fair now: if the article says it's 15x faster, people are going to cite that as saying that node.js is 15x faster than Ruby on Rails without describing the interactions. The "Mobile API server" is really a thin layer over an internal API server, so it's 99% I/O bound. If it's still being hosted outside the main data center, it's I/O bound making HTTP calls across the entire interweb. If it looks like the native app is taking 2 seconds to load something, that's probably a second to reach the API server, and another second to make calls to another API server written in Java. Last I heard, the Ruby on Rails stuff was running on MRI/Phusion Passenger (I don't know if they ever did the full conversion to JRuby; I know that team hosted a lot of stuff half/half. Why Ruby on Rails? Well, we wrote that code in 2008, so don't shoot us. It's was bleeding edge at the time).

What I would have liked to have seen was an evaluation of Netty, but I guess node.js helps your recruiters nail the hipster hackers; Netty doesn't.

Post has attachment

Post has attachment

Hoje o Arraia vai ser foda na #beerrep!

Gabriel Oliveira jovem!
Wait while more posts are being loaded