Puncture Closures to Create Wormholes

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!1

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!

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

Get Tweets with MooTools

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.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

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.


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.


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.


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

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

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.

The method “secret” cannot be called.

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

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.

About Me

I'm Scott Kyle, a MooTools developer and Apple addict. You can follow me on Twitter, fork me on GitHub, and check out some of my work on my portfolio.