Look ahead matching

Let’s say you have five people. Daniel, Dustin, David, Damarcus, and Russ. Now let’s say a user types in dus. We would match Dustin and Damarcus. Likewise, if we typed in us, we would get an output of Dustin, Damarcus, and Russ.

Enter RegExp

At this point, it’s sort of a no-brainer. Your input-based regular expression can be created as such:

var people = ['Daniel', 'Dustin', 'David', 'Damarcus', 'Russ'];

function matchPeople(input) {
  var reg = new RegExp(input.split('').join('\\w*').replace(/\W/, ""), 'i');
  return people.filter(function(person) {
    if (person.match(reg)) {
      return person;
    }
  });
}

Voila! Now you never have to type another vowel again! (At least in spirit… you know what I mean). In addition to this, you can do further post-process sorting based on Levenshtein distance which will graduate better matches to the top.

An Aside: Caching

Since this tends to do be heavy on regular expression construction, a good idea would be to cache your compiled expressions. This can easily be done using my Cache Provider as such:

var regCache = new CacheProvider;

function matchPeople(input) {
  var reg = regCache.get(input) || regCache.set(input, new RegExp(input.split('').join('\\w*').replace(/\W/, ""), 'i'));
  // etc...
}

Now any subsequent calls to the same input will run against a pre-compiled expression. And that folks, is all I got for the night. Cheers.

Starting Simple

function CacheProvider() {
  // values will be stored here
  this._cache = {};
}

Feature detect on local storage

try {
  CacheProvider.hasLocalStorage = ('localStorage' in window) && window['localStorage'] !== null;
} catch (ex) {
  CacheProvider.hasLocalStorage = false;
}

The main reason we use try / catch is because despite Firefox supporting it, it can be disabled in your about:config settings and an error will be thrown. A simple if / else will not work.

Next we’ll add support for storing objects into local storage. This technique was borrowed from Christopher Blizzard in his excellent post Saving data with local storage – for which those who didn’t know, you can only store string’s into local storage. Thus we have this…

in / out JSON parsing

if (CacheProvider.hasLocalStorage) {
  Storage.prototype.setObject = function(key, value) {
    this.setItem(key, JSON.stringify(value));
  };

  Storage.prototype.getObject = function(key) {
    return JSON.parse(this.getItem(key));
  };
}

Now for our three core methods, we’ll have get, set, and clear.

Core class functionality

CacheProvider.prototype = {

  /**
     * {String} k - the key
     * {Boolean} local - get this from local storage?
     * {Boolean} o - is the value you put in local storage an object?
     */
  get: function(k, local, o) {
    if (local && CacheProvider.hasLocalStorage) {
      var action = o ? 'getObject' : 'getItem';
      return localStorage[action](k) || undefined;
    } else {
      return this._cache[k] || undefined;
    }
  },

  /**
     * {String} k - the key
     * {Object} v - any kind of value you want to store
     * however only objects and strings are allowed in local storage
     * {Boolean} local - put this in local storage
     */
  set: function(k, v, local) {
    if (local && CacheProvider.hasLocalStorage) {
      if (typeof v !== 'string') {
        // make assumption if it's not a string, then we're storing an object
        localStorage.setObject(k, v);
      } else {
        try {
          localStorage.setItem(k, v);
        } catch (ex) {
          if (ex.name == 'QUOTA_EXCEEDED_ERR') {
            // developer needs to figure out what to start invalidating
            throw new Exception(v);
            return;
          }
        }
      }
    } else {
      // put in our local object
      this._cache[k] = v;
    }
    // return our newly cached item
    return v;
  },

  /**
     * {String} k - the key
     * {Boolean} local - put this in local storage
     * {Boolean} o - is this an object you want to put in local storage?
     */
  clear: function(k, local, o) {
    if (local && CacheProvider.hasLocalStorage) {
      localStorage.removeItem(k);
    }
    // delete in both caches - doesn't hurt.
    delete this._cache[k];
  }

};

How does this work?

Note in the beginning of this post, said Cache Provider was to have optional support for local storage (although it appears to be most of the point). First let’s look at an example sans-local-storage.

getElementsByClassName

var cache = new CacheProvider;

window.getElementsByClassName = getElementsByClassName || function(c) {
  var reg = cache.get(c) || cache.set(c, new RegExp("(?:^|\\s+)" + c + "(?:\\s+|$)"));
  var elements = document.getElementsByTagName('*');
  var results = [];
  for (var i = 0; i < elements.length; i++) {
    if (elements[i].className.match(reg)) {
      results.push(elements[i]);
    }
  }
  return results;
};

Note the next time you work with the same class – it work with a precompiled regular expression instead of constructing a new one.

As another example, for large apps that require i18n, you could cache the compiled HTML strings into local storage.

var i18nCache = new CacheProvider;

if (i18nCache.get('topnav')) {
  $('#nav').html(i18nCache.get('topnav'));
} else {
  ajax('top-nav.tmpl', function(html) {
    i18nCache.set('topnav', html);
    $('#nav').html(i18nCache.get('topnav'));
  });
}

Other than that, have a play, do some caching, and outsource your resources to your users browser. cheers ;)

Ultimately, the goal for the widgets – which would end up on thousands of websites, was to make them as lightweight as possible – so you can’t just go around and make jQuery, YUI, or Prototype a requirement.

Thus, a simple animation class was in order. One that will work in any browser that supports JavaScript – and can animate any CSS property that is enumerable. Eg: height, weight, font-size, top, left… not color, background-image, text-decoration, etc.

Animation class

/**
  * @constructor Animate
  * @param {HTMLElement} el the element we want to animate
  * @param {String} prop the CSS property we will be animating
  * @param {Object} opts a configuration object
  * object properties include
  * from {Int}
  * to {Int}
  * time {Int} time in milliseconds
  * callback {Function}
  */
function Animate(el, prop, opts) {
  this.el = el;
  this.prop = prop;
  this.from = opts.from;
  this.to = opts.to;
  this.time = opts.time;
  this.callback = opts.callback;
  this.animDiff = this.to - this.from;
}

/**
  * @private
  * @param {String} val the CSS value we will set on the property
  */
Animate.prototype._setStyle = function(val) {
  switch (this.prop) {
    case 'opacity':
      this.el.style[this.prop] = val;
      this.el.style.filter = 'alpha(opacity=' + val * 100 + ')';
      break;

    default:
      this.el.style[this.prop] = val + 'px';
      break;
  };
};

/**
  * @private
  * this is the tweening function
  */
Animate.prototype._animate = function() {
  var that = this;
  this.now = new Date();
  this.diff = this.now - this.startTime;

  if (this.diff > this.time) {
    this._setStyle(this.to);

    if (this.callback) {
      this.callback.call(this);
    }
    clearInterval(this.timer);
    return;
  }

  this.percentage = (Math.floor((this.diff / this.time) * 100) / 100);
  this.val = (this.animDiff * this.percentage) + this.from;
  this._setStyle(this.val);
};

/**
  * @public
  * begins the animation
  */
Animate.prototype.start = function() {
  var that = this;
  this.startTime = new Date();

  this.timer = setInterval(function() {
    that._animate.call(that);
  }, 4);
};

The background on its design was from a technique Y.U.I. came up with in its initial launch in the Animation internals. It’s time-based, overclocked, and plays catchup for browsers that tend to run slower. Hence, the animation looks smoother in faster browsers, but does not get ahead of itself.

Bonus

Use transitions when possible. Generally speaking, the faster browsers tend to be ahead of their time anyway, and provide an alternative to animations with CSS transitions – so why not take advantage of this.

transition

/**
  * @static
  * @boolean
  * allows us to check if native CSS transitions are possible
  */
Animate.canTransition = function() {
  var el = document.createElement('foo');
  el.style.cssText = '-webkit-transition: all .5s linear;';
  return !!el.style.webkitTransitionProperty;
}();

How does it all work in practice?

Fade In Example

if (Animate.canTransition) {
  el.style.webkitTransition = 'opacity 0.5s ease-out';
  el.style.opacity = 1;
}
new Animate(el, 'opacity', {
  from: 0,
  to: 1,
  time: 500,
  callback: done
}).start();

In the end, it’s barebones, but works efficiently. If you need more out of it, tweak it to your liking, or really, just use a library – which won’t be uncommon.

Oh right, yeah, almost forgot – these wouldn’t be proper without a demo page. Cheers.

Anyway, let’s have a look at some historical conventions and compare them to newer ones.

Imagine an iterator class that operated on arrays. It could look like this:

// no chaining
var o = new Iter(['a', 'b', 'c', 'd', 'e']);
o.filter(function(letter) {
  if (letter != 'c') { return letter; }
});
o.each(function(letter) {
  append(letter);
});

// with chaining
new Iter(alphabet).filter(remove_letter_c).each(append);

This is a simple because we’re working on a known existing object in memory (the alphabet array). However an easy way to spoil our soup is to make our methods continue to operate without existing objects. Like say, for example, a result set you had to make an async request to the server to get. Thus, imagine making this work:

ajax('/server/results.json').filter(remove_duplicates).append('div#results');

In the grand scheme of things, the above example isn’t too far off from from currying (which it’s not). And to make another point, currying can often lead to bad coupling of code… which in its defense, is often the point as well. Some libraries even call this pattern binding… so… yeah.

Anyway, to the point, here is a basic Queue implementation that can be used as a tool to build your own asynchronous method chains.

function Queue() {
  // store your callbacks
  this._methods = [];
  // keep a reference to your response
  this._response = null;
  // all queues start off unflushed
  this._flushed = false;
}

Queue.prototype = {
  // adds callbacks to your queue
  add: function(fn) {
    // if the queue had been flushed, return immediately
    if (this._flushed) {
      fn(this._response);

    // otherwise push it on the queue
    } else {
      this._methods.push(fn);
    }
  },

  flush: function(resp) {
    // note: flush only ever happens once
    if (this._flushed) {
      return;
    }
    // store your response for subsequent calls after flush()
    this._response = resp;
    // mark that it's been flushed
    this._flushed = true;
    // shift 'em out and call 'em back
    while (this._methods[0]) {
      this._methods.shift()(resp);
    }
  }
};

With this code, you can put it straight to work for something useful, like say, a jQuery plugin that fetches content remotely and then appends the results to your selector input. For you plugin developers our there, it would look like this…

<script src="jquery.js"></script>
<script src="async-queue.js"></script>
<script>
(function($) {

  $.fn.fetch = function(url) {
    var queue = new Queue;
    this.each(function() {
      var el = this;
      queue.add(function(resp) {
        $(el).html(resp);
      });
    });

    $.ajax({
      url: url,
      dataType: 'html',
      success: function(html) {
        queue.flush(html);
      }
    });
    return this;
  };

})(jQuery);
</script>

Then voila! You can make your DOM queries, fetch remote content, and continue your chain, asynchronously.

$("<div/>")
  .fetch('/server/navigation.html')
  .addClass('column')
  .appendTo('#side');

Here’s a brief example of showing off the example above. Point being, one can only imagine the possibilities you could do. Say for example, having multiple items in the queue waiting to operate on a response. Thus imagine this…

fetchTweet(url).linkify().filterBadWords().appendTo('#status');

Your internals would look like this with the Queue.

function fetchTweet(url) {
  this.queue = new Queue;
  this.tweet = "";
  var self = this;
  ajax(url, function(resp) {
    self.tweet = resp;
    self.queue.flush(this);
  });
}
fetchTweet.prototype = {

  linkify: function() {
    this.queue.add(function(self) {
      self.tweet = self.tweet.replace(/\b@(\w{1,20}\b/g, '<a href="...">$1</a>');
    });
  return this;
  },

  filterBadWords: function() {
    this.queue.add(function(self) {
      self.tweet = self.tweet.replace(/\b(fuck|shit|piss)\b/g, "");
    });
  return this;
  },

  appendTo: function(selector) {
    this.queue.add(function(self) {
      $(self.tweet).appendTo(selector);
    });
  return this;
  }

};

And with that, you can call it a night. Cheers.

I’ve been a bit under the blog radar this last year. @Erin and I have been busy with our separate jobs, also creating our joint photography effort with Flash Bullet having done a dozen shoots the last few months. I’ve remained stagnant with my own personal photography having not being able to fully recover from last years 365.

Work @Twitter has kept me busy. A small group of us (@dsa, @todd, & @danwrong) had been heads down for the last two months trying to release something that we think will effect billions of lives called @Anywhere. We think it’s great.

For the 90% of you reading this because it was once a JavaScript blog, my hope is for it to remain as such. It is in fact still the main thing I do. Speaking of which, if you haven’t had a play yet, dive into our Twitter JavaScript API preview. Some folks already have. Pending more test coverage, we’ll release this into a stable release version. Thus the idea being anyone can build a fully featured Twitter web-client with pure client-side scripting.

On another note, I’ve taken a side step to help the redesign effort that some of you may have already seen. This too should be quite good. It’s pretty obvious that our feature set has out-grown our current Twitter.com experience, so we’re finally doing something about it…. and more.

Other than that, some final changes include:

• A new TV
• A full bar sits in my living room
• Erin has an American visa
• I like fish, more

Cheers.

So, what’s this do?

The Twitter Search Widget allows you to track any topic, live, in real-time. You can even use our advanced search operators which dogfoods straight into our own search API.

So what are these other features?

Well, for the advanced JavaScripters; or actually, I should say, ANYONE who can read JavaScript should be able to try some of these things out on your own. Which brings us to the hidden undocumented features

But first…

Let’s look at the base widget code to start off with.

base twitter widget code

<div id="twtr-search-widget"></div>
<script src="http://widgets.twimg.com/j/1/widget.js"></script>
<link href="http://widgets.twimg.com/j/1/widget.css" type="text/css" rel="stylesheet">
<script>
new TWTR.Widget({
  search: 'my search query',
  id: 'twtr-search-widget',
  loop: true,
  title: 'what people say about...',
  subject: 'stuff and things',
  width: 250,
  height: 300,
  theme: {
    shell: {
      background: '#111',
      color: '#000000'
    },
    tweets: {
      background: '#000000',
      color: '#ffffff',
      links: '#f59f00'
    }
  }
}).render().start();
</script>

What this does is load our base functionality and stylesheet. It then instantiates a new Widget object, and points to an id representing an HTML element. What this tells you already is that you could technically have multiple widgets on a page by simply instantiating new objects, populating existing <div> elements. Hey, you could create your own web version of tweet deck this way by stacking a few of them into columns :)

The features object

So there is a features object that you can pass into your constructor. There are currently four of these features.

the features object

new TWTR.Widget({
  id: 'my-element-id',
  .
  .
  .
  features: {
    hashtags: true,
    timestamp: true,
    avatars: true,
    fullscreen: false
  }
}).render().start();

Albeit mostly self explanatory, they each do this:

• hashtags: defaults to true. setting to false will hide them.
• timestamp: defaults to true. setting to false will hide them.
• avatars: defaults to true for search. and false for profile widget. setting to false will hide them.
• fullscreen: (I love this feature!) defaults to false. setting to true will give you a full viewport sized widget, perfect for displaying on large screens at events, conferences, etc.

Overall, these features are pretty great. I especially love the hashtag and fullscreen features since they are perfect for pairing.

Let’s say for instance you’re running a conference like SxSW — you could search for “#sxsw OR #sxsw09″ — and in the results, hide the hashtags so it doesn’t distract the readability of all the searches. Neat, eh?

Some examples

I went ahead and installed the widget on my own site — And here’s a few examples:

• fullscreen, hidden hashtag search for #iranelection
• fullscreen iphone to:apple (hey, we all do it)
• Or sometimes you just want to know what Evan Weaver is doing

That’s it for now

This will all undoubtedly be on our FAQ website soon enough, but it’s enough to have a play.

Happy Twidget Searching!

If any of you use our Twitter API to embed your latest statuses on your website, here is a simple little script that will do a few niceties for you. This includes linkafying, hashtagifying, and of course the most important, atify (aka: “at replies”). check out the source, and use it as such:

tweet code

ify.clean('your tweet text');

Thus making transforming a tweet such as the following:

Before and After

Bfore
Hey @ded. You should #stfu! and use http://canon.com #rant.
kthxbye @erin http://www.google.com/search?q=canon+rules

After
Hey @<a href="http://twitter.com/ded">ded</a>.
You should #<a href="http://search.twitter.com/search?q=%23stfu">stfu</a>!
and use <a href="http://canon.com">http://canon.com</a>
#<a href="http://search.twitter.com/search?q=%23rant">rant</a>.
kthxbye @<a href="http://twitter.com/erin">erin</a>
<a href="http://www.google.com/search?q=canon rules">

http://www.google.com/se...</a>

Download: source | minified

With that said, if you like one and not the other, this should still at least be entertaining and educational. If you like both, then you’re in for a treat of nerdy euphemisms and theories.

Hold on a sec… Photography? Really?

Yes, really. If you haven’t noticed, I’ve started my very own 365 Project where I take at least one photo a day, and post it there. There’s even a handy RSS feed you can drop into your favorite Reader. Anyway…

Photography and JavaScript are similar because…

• They are expressive: This is almost a no-brainer. Since the beginning of having the ability to take a picture of something, the expression “a picture says a thousand words” has held true to this day. This also great for people who aren’t fantastic with words. This spills into JavaScript because it is one of the smallest object oriented languages on the planet and allows you to express behavior and action in a variety of ways. The mere fact that we have such a plethora of JavaScript libraries these days is testament to how expressive it really is, especially since most of them pretty much do the asme thing! Just differently.
• They can be as simple or as complicated as you make them: I’ve always said that JavaScript is the closest thing we have to a ninja, but in written lexical structure. As previously mentioned, it’s a small language. But it can be very, very complicated at times, especially when you dive into JavaScript Design Patterns and begin to learn about subclassing, information hiding, prototypal inheritance, and all that other fun good stuff. Same holds true for photography in that the scientific break-thru of capturing light (onto film or a digital sensor), and modifying it by means of shutter speed and aperture, is so simple that anyone can get started taking pictures on a manual camera. On the flip side, you can turn it into a really complicated and complex hobby (or profession) by introducing flash, wireless remote systems, then umbrellas, soft boxes, snoots, grid spots, gobos… there’s also a giant pile of lenses you could buy; macros, telephotos, wide-angles, primes, zooms… the list can go on. There’s a reason why there are dedicated camera stores like B&H Photo, Calumet Photo, unfortunately there aren’t exactly stores like this for JavaScript ;) — I guess that’s what Apress and O’Reilly are for (which sells both photography and JavaScript books :)
• they are both object oriented and subject driven: Clearly, JavaScript is object oriented, there’s no argument on that (seriously, don’t get us started), but often the subject of what we’re programming for drives how we use the language. When you’re building a library, you’ll most likely use the languages object oriented features. When you’re implementing interfaces and dealing with simple tasks, you’ll use more functional JavaScript. Same goes for photography where the subjects should drive the type of photos you’ll take. When I’m going to shoot a small plant, I’m not going to pull out my wide angle, I’ll pull out a macro or telephoto. When I’m doing portraits, I’ll grab my prime 85mm. For more serious work, I can begin to create my own light with strobes. Maybe even two or three of them. And of course the real reason photography is object oriented, is because it evolves around taking pictures of objects. Of course don’t call people objects (which is slightly inappropriate), they are more or less subjects.

And so the list goes on

I could probably continue on, but I’m pretty sure most of the point has been proven. This stuff is fun for a reason, and I’ve always known that in one way or another, the two have been connected. Something about my brain latches on to simplicity with the ability to evolve. Kind of like Gmail (but this is not the forum for that). Cheers everyone, and happy Friday!

Now I’d like to invite you to yet another brain teaser, except this time your answer must require a regular expression. If you solve it, I would urge you to buy yourself a t-shirt ;)

The Problem

Write a function that takes a text input (first argument), and an integer specifying the amount of duplicates (second argument) to begin the grouping. View the following code as our skeleton:

empty function

function bookend(text, start) {
  // return modified text
}
var example = 'a a a a a a a a a bb bb c c c c d a dd dd dd dd dd dd';

var result = bookend(example, 3);
// result is 'a a a (a a a a a a) bb bb c c c (c) d a dd dd dd (dd dd dd)'

var result2 = bookend(example, 4);
// result2 is 'a a a a (a a a a a) bb bb c c c c d a dd dd dd dd (dd dd)'

In English

Bookend all duplicates that begin after the specific amount of minimum duplicates. Therefore if you specify the offset of ‘4′ as your argument, and there are six duplicates in a row, then bookend the final two. Also take special note of the spaces in the examples.

Assumptions

You can assume your text input will only be a mix of letters (eg: “\w+”), and that nothing is separated by more than a single space.

Sharing

If you come up with a solution, post them offsite. I’d recommend Pastie.org.
Happy RegExing!
Cheers!