AppDen

Puncture Closures to Create Wormholes

2009-12-09T00:00:00-08:00

Have you ever wanted access to a closure’s precious private variables? Has static scoping got you down? Well put your mind at ease, and worry no longer!¹

Function.prototype.puncture = function(){
  var wormhole = function(__cmd__){
    return eval(__cmd__);
  };

  var source = ('' + this).match(/function.+?\{([\s\S]*)\}/)[1];
  var fn = new Function('this.wormhole=' + wormhole + '\n' + source);

  fn.prototype = this.prototype;
  for (var prop in this){
    if (this.hasOwnProperty(prop)) fn[prop] = this[prop];
  }

  return fn;
};

Now I know you’re excited, and probably asking yourself how you can start puncturing closures today. Well here’s an example of how it works!

var WellDesignedClass = function(){
  var secret = 'Nobody can access this variable, muahahaha';
};

var PuncturedClass = WellDesignedClass.puncture();
var useless = new PuncturedClass;
var secret = useless.wormhole('secret'); // not so secret anymore!

You can watch this gist for improvements on this must-have plugin!

¹ This code merely proves a concept. It could be fleshed out to actually accomplish things, but that would be insane.

Get Tweets with MooTools

2009-09-19T00:00:00-07:00

To give this site a little dynamism, I decided (as many others have) to pull my latest tweets into the rather barren sidebar. David Walsh’s TwitterGitter was a good start, but I saw some room for improvement by subclassing Request.JSONP. The result is a great example of how MooTools grants you a great deal of object oriented power. I kept David’s linkify method (with some regex tweaks) because it is awesome.

Request.Twitter = new Class({

  Extends: Request.JSONP,

  options: {
    linkify: true,
    url: 'http://twitter.com/statuses/user_timeline/{term}.json',
    data: {
      count: 5
    }
  },
  
  initialize: function(term, options){
    this.parent(options);
    this.options.url = this.options.url.substitute({term: term});
  },
  
  success: function(data, script){
    if (this.options.linkify) data.each(function(tweet){
      tweet.text = this.linkify(tweet.text);
    }, this);
    
    // keep subsequent calls newer
    if (data[0]) this.options.data.since_id = data[0].id;
    
    this.parent(data, script);
  },
  
  linkify: function(text){
    // modified from TwitterGitter by David Walsh (davidwalsh.name)
    // courtesy of Jeremy Parrish (rrish.org)
    return text.replace(/(https?:\/\/[\w\-:;?&=+.%#\/]+)/gi, '<a href="$1">$1</a>')
               .replace(/(^|\W)@(\w+)/g, '$1<a href="http://twitter.com/$2">@$2</a>')
               .replace(/(^|\W)#(\w+)/g, '$1#<a href="http://search.twitter.com/search?q=%23$2">$2</a>');
  }
  
});

Hopefully the code speaks for itself. I’ll keep this Gist updated with any bugfixes.

Journey to Jekyll

2009-09-06T00:00:00-07:00

I did it. I’ve freed myself from the shackles of a database, excessively complex blogging software, and many wasted computing cycles. I’ve escaped to the greener pastures of text and git with Jekyll, the same engine that powers GitHub Pages. You can too!

It’s very simple, check out this site’s source to see what I mean. Feel free to “steal” my code. I kept it general enough where changing the YAML and CSS will give you a brand new working blog. It’s hard to even describe how easy it will be to manage this site thanks to Jekyll. It’s so simple and powerful, yet young and full of potential.

Deploys

Tate Johnson has an excellent post on setting up deploys to DreamHost using git push, but I wanted my setup to be even simpler so I opted for rsync controlled by Rake. This translates into needing zero setup on the server, just sudo gem install jekyll on your machine to develop locally. See my Rakefile if you’re curious, it’s very easy to understand once you see it.

Comments

Easy. DISQUS. Done. Next question.

Movable Type

Movable Type provides hideous default templates and a very programmer-unfriendly template language. While I believe it’s cleaner than Wordpress, it still suffers from having being too complicated for the average blogger. The experience of editing templates is dreadful, unless you have manually “linked” each individual template to a file then setup SVN hooks to update those files and trigger a full rebuild of your site. Even after all that, it’s still awful, and don’t get me started on maintaining a separate development version of your blog.

Conclusion

This site is now completely naked, the source exposed for all the world to gawk at on GitHib, so check it out. I’m loving the feeling of complete transparency, it forces me to write better quality, more generic code. Thanks to Jekyll, I’ll be able to happily further develop my site, rather than dread touching it.

Predictions for the Next iPhone

2009-06-21T00:00:00-07:00

The iPhone 3GS has been all the rage, and admittedly I’m still pondering the upgrade from my 3G. Sure, I can nab it for $200 from AT&T and sell my current one to cover the costs, but what about next year? Will AT&T allow full subsidized price again to those who already took advantage of it twice within two years? I’m not so sure.

So I think I’ll wait for the next iPhone, and in the interest of saying “I told you so,” I am making the following predictions for it and the 4.0 OS.

iPhone 4th Generation (though probably not 4G)

OLED Display — That’s right. I see this being its biggest differentiator. It’ll be bright, vivid, energy efficient, and sexy as hell. When seen next to an older model, there’ll be absolutely no comparison, and again Apple will have raised the bar for all other mobile devices that follow.
Multi-core — This has already been speculated on AppleInsider, and I suggest you read more about it there if you haven’t already. See below for my prediction on backgrounding support for third party apps.
Faster Networking — I see this coming in the form of 802.11n support, which will work really nicely with WiFi Syncing (see below). They just introduced HSDPA 7.2 Mbps support in the 3GS and AT&T still has to play catch-up, so I don’t think the 4th-gen will really be 4G, as in WiMax or something similar.
Minor Cosmetic Update — Time to thin it out a bit and visually differentiate it from the 3G and 3GS. I have a hunch that they may offer a wider range of color options, as the iPods do.
Better Battery Life — Time to steal some tech from the MacBook division to keep 3G network users happy.
Same camera — I see another camera update coming in the following model, not this one. Also, I really don’t expect a front camera for video chatting. It just wouldn’t get used by the vast majority of users.

iPhone 4.0 Operating System

WiFi Sync — It’s something I’ve always wished for more than copy & paste and I believe 4.0 will make it a reality. The programming is mostly there with the Apple TV and MobileMe, and with MMS and copy & paste out of the way, I think we’ll start to see this more on iPhone wish lists.
Reimagined Home Screen — The current home screen design is already buckling under the weight of the more and more apps that people are loading onto their phones. The new design will still be very “iPhone-esque,” but will make launching and organizing large numbers of apps much easier for the user.
Limited Multi-tasking Support — We have push now, but the Pre has a nice card-centric UI for running multiple apps at once. I see Apple allowing something similar, but with reasonable limitations, in 4.0 for both the 3GS and the 4th-gen model. The 3GS has the horsepower but may need more limitations, while with two cores, the 4th-gen will practically be made for this sort of thing. I can see them adding a certification process for apps that want to be able to run in the background.

Also, I predict that Google will soon beef up their iPhone app offerings with GMail and maybe Docs. At the same time, they’ll expand push support to the iPhone. There’s already offline support, but you still have to use it in Safari, which definitely is a limitation.

There you have it, all my iPhone related predictions. I’ll give myself a report card after the next WWDC.

I’ve neglected this infant blog for too long. I apologize if you feel like it’s been wasting precious space in your feed reader. My attention has been all over, and sometimes I second guess posting about a topic becuase I feel it’s been covered well enough elsewhere. I’m about to embark on my month-long vacation kayaking in Oregon and backpacking through Europe, but I have many blog post ideas for when I return.

Protect Your Class Methods from Evildoers

2009-05-04T00:00:00-07:00

With the advent of MooTools 1.2.2 comes the ability to mark Class methods as ~~private~~ protected. Let’s take a look at some code.

var Person = new Class({

  initialize: function(name){
    this.name = name;
  },

  secret: function(){
    return 'I sometimes like girly drinks';
  }.protect(),  // <== MAGIC SAUCE

  describe: function(){
    return "Hi, I'm {name}. {secret}. I kid, I kid.".substitute({
      name: this.name,
      secret: this.secret()
    });
  }

});

var scott = new Person('Scott');

Notice the protect call on the secret method. It prevents outsiders from calling that method and believing false facts about that person.

scott.secret();
The method “secret” cannot be called.

It can, however, be called from within an another method.

scott.describe();
Hi, I’m Scott. I sometimes like girly drinks. I kid, I kid.

There you have it — a cool, new, undocumented feature available now in MooTools 1.2.2!

As I mentioned in my previous article, I have a working implementation of a Privates mutator (to privatize variables) for the latest version of MooTools, but I am waiting to see how post-initialization mutators will look in More. It’s something I’ve discussed at length with Aaron Newton, and hopefully will be available soon.

BindAll Class Mutator for Saving Your Sanity

2009-04-14T00:00:00-07:00

MooTools is just the best JavaScript thing ever. And I say that totally subjectively because I honestly don’t have much experience with anything else other than jQuery. Some of the design decisions are nothing short of genius — custom events, element properties, and class mutators — to name a few.

The Binds mutator is particularly headache relieving. My only issue with it is that you need to list out all the methods you want bound, which somehow, I am very prone to jacking up due to forgetfulness or quick refactoring.

Binds : ['update', 'include', ...]  // yadi yada

So since I have nothing better to do in the airport than watch a depressing House episode, I figured I’d write my own BindAll mutator to save myself from my own misery (and maybe save you from yours).

Class.Mutators.BindAll = function(self, bool) {
  if (!bool) return self;      // mutate or get out
	
  var init = self.initialize;  // save original, if there is one
  var exclude = arguments.callee.exclude;

  self.initialize = function() {
    for (var method in this) {
      if (typeof this[method] != 'function' || exclude.contains(method))
        continue;
			
      var unbound = this[method];
      this[method] = unbound.bind(this);
      this[method].__parent = unbound.__parent;
    }
    // if there was an original initialize, run it
    return init ? init.apply(this, arguments) : this;
  };
	
  return self;
};

Class.Mutators.BindAll.exclude = ['constructor', 'initialize', 'parent'];

With this, all methods get bound, and it’s this simple:

BindAll : true  // or anything else truthy

So now, class methods can be passed around without fear of them forgetting who this is:

$('flashing_red').addEvent('click', self.destruct);

This might not be for everyone, but for me, I can’t see why I wouldn’t want all my methods to be bound properly, and if I do run into that scenario, then I’d fall back to the regular Binds mutator. I also made the function name exclude list accessible to the programmer to add more if needed. Bugfixes will be made on the GitHub Gist.

Another class mutator that has gotten a fair bit of my attention is Privates, which has had many implementations, including Nathan White’s (deeply flawed), Thomas Dullnig’s (flawed), and Sean McCarthur’s (not flawed, but not pretty either). I’ve totally embarrassed myself in an email to Aaron Newton over the matter, essentially arguing the inclusion of Nathan White’s implementation into More before realizing that it was creating a bunch of global variables. Soon, I’ll write about my own implementation that I just made, as soon as I quadruple check that it isn’t flawed as well. That one will need specs!

Safari 4 Beta Breaks `Class.implement()`

2009-04-08T00:00:00-07:00

I just spent a few hours tracking down this lovely bug that broke my portfolio page in Safari 4 Beta (build 5528.16). If you add a property to a constructor’s prototype after initializing an object from that constructor, then that new property will not be enumerable in a for-in loop (presumably it’s been mistakenly marked DontEnum).

(update: The May 12th update to Safari 4 – build 5528.17 – fixes this issue, woohoo)

I first discovered this when the oneEvent method that I added to the Events Class was not getting implemented into my other Classes. The JS.Class blog mentioned a Function.prototype enumeration bug that may be related, but other than that I couldn’t find any mention of this problem on Google.

Here is the reduction that I submitted to Apple:

// constructor
var House = function() {};
House.prototype = {
  garage : 1,
  yard : 1
};

// this works
var house = new House;
for (var prop in house)
  print('house has a ' + prop);

// add a new property after using constructor
House.prototype.pool = 1;

// we can see the pool in the prototype
for (var prop in House.prototype)
  print('blueprint contains ' + prop);

// enumeration won't find the pool
var mansion = new House;
for (var prop in mansion)
  print('mansion has a ' + prop);

// but the pool is there
print('check for pool in house...' + !!house.pool);
print('check for pool in mansion...' + !!mansion.pool);

function print(line) { document.write(line + '<br/>'); }

Which in Safari 4 Beta, yields…

house has a garage
house has a yard
pool now added to blueprint
blueprint contains garage
blueprint contains yard
blueprint contains pool
mansion has a garage
mansion has a yard
check for pool in house...true
check for pool in mansion...true

The line, mansion has a pool, is never printed in Safari 4 Beta! It does, however, get printed in the latest Webkit Nightly, but I’m not sure when this bug was fixed and if Apple has merged that fix into their Safari 4 branch. I hope they have already, and if not, that they do so when they read my bug report.

I hope this helped put somebody’s mind at ease.

Element Creation Shortcut in MooTools

2009-04-01T00:00:00-07:00

Lately, I’ve been bothered about the amount of typing and lines required to create a simple element in MooTools.

var curly = new Element('div', {
  id : 'curly',
  'class' : 'stooge'
});

In jQuery, you’re given the convenience of writing HTML into the jQuery function —

var $curly = $('<div id="curly" class="stooge" />');

To me, this is quick and easy, but it’s very unnatural typing HTML into JavaScript and I’ve seen this convenience become quickly (and horrifyingly) abused.¹ MooTools deserves something cleaner and cooler, so today I realized I could use a limited selector to create an element. I liked that idea very much.

var curly = $E('div#curly.stooge');

(update: Apparently I’m not the first to think of this. A couple weeks before I wrote this post, this commit was made to MooTools 2.0 adding this capability to new Element. The idea came from Thomas Aylott. I am so happy to see this become a part of the next version of MooTools!)

I know, $E was used in MooTools 1.1 for finding an element by a selector with an optional filter, but that is longer the case in MooTools 1.2. Besides, $A and $H are used for to create a new array or hash, respectively, so it seems only natural to me to use $E for creating an element. If you don’t like my reasoning, then you can change the name and I promise I won’t hunt you down.

function $E(tag, props) {
  if (typeof props == 'string')
    props = { style : props };
  if (typeof tag == 'string') {
    var id = tag.match(/#([\w-]+)/);
    var classes = tag.match(/(?:\.[\w-]+)+/);
    tag = tag.replace(/[#.].*/, '');
    props = props || {};
    if (id) props.id = id[1];
    if (classes) props['class'] = classes[0].replace(/\./g, ' ');
  }
  return new Element(tag || 'div', props);
};

(edit: a style string can now optionally be passed into props, further updates will be on GitHub here)

With this new magical utility function, you can quickly and easily create elements with an optional id and any number of classes, along with additional properties passed into the optional second argument. In fact, you can omit a tag and it’ll default to a <div>.

var moe = $E('#moe.stooge.leader', {...});

I’m pretty excited about using this new shortcut, and I hope you are too. Please shout out in the comments if you find it useful or have any tweaks.

Note to plugin developers: If you decide to use this, please place it inside of a closure so it doesn’t override someone else’s $E function. I saw this suggestion on the MooTools Twitter² so I can imagine this becoming a problem —

$E = document.getElement.bind(document);

¹ Some even prefer to use double quotes and then escape all the attribute quotes. Ughh!

² My last post on custom events was linked there!

Fun with Custom Events on Elements in MooTools

2009-03-29T00:00:00-07:00

Tonight, I’ve been playing with the fantastic MooTools plugin, ReMooz by Harald Kirschner, with the hope of adapting it for my upcoming web portfolio. One of the pieces of functionality I was looking for was to close the zoom box when the user clicks outside of it. The solution I thought had the most Moo was to create a custom event¹, clickout.

(update: I just discovered Jan Kassens blogged a similar custom event, outerClick. We took very different approaches, but I thought I’d give proper credit)

Element.Events.clickout = {
  base : 'click',  // attach click event to element
  condition : function(event) {
    event.stopPropagation();  // stop event from bubbling up
    return false;  // never run handler when clicking on element
  },
  onAdd : function(fn) {
    this.getDocument().addEvent('click', fn);
  },
  onRemove : function(fn) {
    this.getDocument().removeEvent('click', fn);
  }
};

(edit: fixed bug that prevented links from working inside the element, further updates will be made on GitHub here)

The condition of the custom event is executed each time the base event is fired to with a return value that determines if the handler should be run. The condition above prevents the click event from bubbling² up to the body, where the handler will actually be attached in the onAdd callback. This effectively runs the handler passed into the clickout event when anywhere on the page is clicked except inside the element where the event was attached. For example, in ReMooz I wanted to add this event to the zoom box when it is opened.

ReMooz.assign('.thumb', {
  ...
  onOpen : function() {
    this.box.addEvent('clickout', this.close.bind(this));
  },
  onClose : function() {
    this.box.removeEvents('clickout');
  }
});

The event must be removed when the zoom box is closed so the click event attached to be body is also removed. If the zoom box didn’t have a close button in it, then I could have applied a singular event³ pattern like the jQuery.one() method, recreated in MooTools below:

Native.implement([Element, Window, Document, Events], {
  oneEvent : function(type, fn) {
    return this.addEvent(type, function() {
      this.removeEvent(type, arguments.callee);
      return fn.apply(this, arguments);
    });
  }
});

(edit: thanks to gonchuki for the idea of using arguments.callee, further updates will be made on GitHub here)

This allows you to attach an event that only will be run once and then automatically detached. The only problem with ~~this method~~ oneEvent() is that its implementation doesn’t allow you to remove a specific handler with the removeEvent() method; you must use removeEvents() instead to remove all events of ~~a certain type~~ the type you added with this method. jQuery doesn’t have this problem because it uses an event proxy, so you can still unbind a specific handler. With a little refactoring, MooTools could allow the same kind of functionality, though the real-world usage of this pattern is admittedly rare.

I deeply apologize for becoming so serious in this post, I’ll try to be funnier next time!

¹ Check out the super cool demo and sample code for more info on custom events.

² A quick refresher course on event bubbling, if desired.

³ I just made that term up. I hope it sticks.

Lazy List Comprehensions in JavaScript, a Lazy Evaluation

2009-03-25T00:00:00-07:00

A while back I made Proggit a regular stop on my daily Internet stroll. I was struck by the readers’ apparent bias toward Haskell and thought, What the Hell, I should at least attempt to learn something new today. It was here that I had that lazy evaluation Eureka moment. So of course, I then thought to myself, How can I get a piece of that sweet functional programming action in JavaScript?

For the uninitiated, lazy evaluation is, in a nutshell, the concept of a program not computing the value of something until absolutely needed. This is especially useful for long (perhaps even infinite) lists that would cause severe nausea or swelling to compute ahead of time. The example I read about used the Fibonacci sequence to butter up my brain, so that is what I will use here to electrify yours.

Quite simply, I wanted the constructor of my Lazy List to take a definition function, such as the following for the Fibonacci sequence:

function fibs(i) {
  return i <= 1 ? i : fibs(i - 1) + fibs(i - 2);
}

But why would anyone need anything beyond the fibs function written above? If the unlikely programmer who needs the tenth member of the Fib sequence, just ran fibs(10), she would happily get 55 as the answer. Ahh, but she may want the eleventh member shortly thereafter…

Yes, indeed, she needs a simple caching mechanism. This is a recursive definition we’re talking about here, not exactly cheap labor. So here is my first attempt at giving that poor unlikely programmer just what she needs:

// my lazy constructor
function Lazy(def) {
  var cache = [];

  return function(i) {
    return (i in cache) ? cache[i] :
      (cache[i] = def.call(arguments.callee, i));
  };
}

// a more awesome Fibonacci sequence
var fibs = new Lazy(function(i) {
  return i <= 1 ? i : this(i - 1) + this(i - 2);
});

There, now she must be happy. When she wants that eleventh number in the sequence, the ninth and tenth will already be cached and ready to be added together to give 89 as the result. One little goodie I snuck in there was binding the definition function to the generator so we can conveniently call it with the keyword, this. Also, using the new operator is optional, though I find it more canonical to use since we are creating a new generator when calling the constructor.

When pushing the limits of our cool new sequence, our happy but unlikely programmer will eventually hit a brick wall of “too much recursion”, though how soon that occurs very much depends on the browser she is using. Hopefully, when fed up with our simple solution, she’ll fire up Firefox 3 to enjoy its native generator expressions in JavaScript 1.8]

Array-like methods, such as slice and forEach, can be added to our generator, but that will be left as an exercise for the reader (unless you pay me).

¹ For more of the bleeding edge, read John Resig’s rundown of JavaScript 1.8 and Mozilla’s coverage of JavaScript 1.7