Local Wildcard Domains on OS X

2013-02-26T00:00:00-08:00

This post shows how to map *.dev domains to localhost and make them accessible from within VirtualBox.

Adding an IP alias

By default VirtualBox maps the IP 10.0.2.2 to the host’s loopback interface. So instead of mapping *.devdomains to 127.0.0.1 as one would normally do we let them resolve to 10.0.2.2 and set up an IP-Alias for the loopback interface. In order to permanently add the alias we have to put this plist file into the /Library/LaunchDaemons/:

# Download the gist
sudo curl https://gist.github.com/fgnass/5037138/raw/676369616ee8ba5f8c77a9b32d2a60ecd05edaf0/ipalias.plist -o /Library/LaunchDaemons/ipalias.plist

# Let launchd execute the command
sudo launchctl load /Library/LaunchDaemons/ipalias.plist

To verify that the command was executed successfully run sudo ifconfig lo0 | grep 10.0.2.2 which should display the following output:

inet 10.0.2.2 netmask 0xff000000

Installing a DNS forwarder

To actually resolve the *.dev domains we install dnsmasq a lightweight DNS forwarder:

# Install dnsmasq via homebrew
brew install dnsmasq

# Resolve *.dev domains to 10.0.2.2
echo "address=/.dev/10.0.2.2" > `brew --prefix`/etc/dnsmasq.conf

# Launch on Startup
sudo cp `brew --prefix dnsmasq`/homebrew.mxcl.dnsmasq.plist /Library/LaunchDaemons
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

# Use dnsmasq as nameserver
sudo bash -c 'mkdir /etc/resolver && echo "nameserver 127.0.0.1" > /etc/resolver/dev'

You should now be able to ping foo.dev as well as any other .dev domain.

Setting up the nameserver in your Virtual Machines

The last step is to tell your VMs to use 10.0.2.2 as DNS-Server. Under Windows this looks like this:

If you spot an error please create an issue or drop me a line on twitter.

Serving PHP files with Yeoman

2012-08-30T00:00:00-07:00

I recently did some PHP development and thought it would be nice if I could use Yeoman’s built-in development server to serve dynamic files, too.

The first step was to install php-cgi which isn’t included with OS X.

brew tap homebrew/dupes
brew tap josegonzalez/homebrew-php
brew install php54

The next step was to add a middleware to Yeoman’s server in order to invoke the PHP interpreter for all files ending with .php.

I found the node-cgi module that Nathan (@TooTallNate) had written to serve the GitWeb interface through Node, but unfortunately node-cgi only handles scripts with a shebang that are located in a cgi-bin directory.

I needed a module that would serve scripts from arbitrary locations and choose the interpreter based on the file’s extension. As it should also support welcome-files so I decided to roll my own.

While Yeoman was now able to serve PHP files, one important aspect was still missing: The server had to inject the liverelaad snippet into the response that was generated by the PHP interpreter.

Hence I wrote a second middleware called tamper. What tamper does is that it temporarily overwrites the write(), writeHead() and end() methods of the ServerResponse object. Before the headers are sent to the client, tamper invokes a callback function that decides whether the response body should be captured or whether it should be streamed to the client without further tampering.

With these two little patches yeoman server now happily serves PHP files. You can watch the screencast below to see the live reloading in action:

Better than templates

2012-02-22T00:00:00-08:00

When I saw a project called Jade for jQuery being featured on DailyJS yesterday I thought I should take the time and promote my lightweight Jade/HAML-style DOM builder I wrote some month ago.

In his jQuery Roundup Alex Young writes about jQuery and Jade:

Seeing as both of these technologies are all about CSS selectors, I’ve always felt like it makes sense to use them together.

I agree that using CSS selectors not only to query but also to create elements makes a lot of sense. But using a rather huge templating library like Jade on the client feels just wrong.

What I wanted instead was a jQuery-flavored wrapper around the native DOM API that made it easy to create DOM trees leveraging CSS selectors the same way Jade and HAML do.

Neil Jenkins makes some excellent points why using the DOM instead of templates is a good idea:

No need to query the DOM, as you can just save references to nodes you’ll need later as you create them

No escaping worries; zero chance of XSS bugs

JSHint will validate your syntax

Flexibility to use the full power of JS; easily call other functions to generate parts of your DOM tree

He has also written a JsPerf test that shows that using the DOM API is up to 50% faster than using innerHTML in modern browsers.

Let’s build some elements m’kay

M’kay is a tiny (556 bytes) plugin for jQuery or Zepto.js. You can use it like this:

var items = 'Click on one of these'.split(' ');

$('body').mk('#message')
  .mk('a.big', "M'kay on GitHub").attr('href', 'https://github.com/fgnass/mkay')._
  .mk('ul', $.map(items, function(text) {
      return $.mk('li.item', text).click(function() {
        alert(text);
      });
  }));

This will generate the following HTML and add a click listener to each item:

<div id="message">
  <a class="big" href="https://github.com/fgnass/mkay">M'kay on GitHub</a>
  <ul>
    <li class="item">Click</li>
    <li class="item">on</li>
    <li class="item">one</li>
    <li class="item">of</li>
    <li class="item">these</li>
  </ul>
</div>

You can play with the example above here on JsFiddle. For sources, tests and documentation please refer to the GitHub project page.

Inheritance In Node

2012-02-16T00:00:00-08:00

I usually try to avoid using inheritance in JavaScript altogether but sometimes there are situations where using a classic OO-style can make things easier.

Let’s assume we have a class Foo which we want to extend:

function Foo() {
  // constructor code
}
Foo.prototype = {
  bar: function() {
    // do something
  }
};

A common pattern is this:

function Bar() {
}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.bar = function() {
  // do something else
};

In contrast to the original definition of Foo this code looks quite noisy.

Using util.inherits()

In Node.js there’s the util.inherits() function which helps us to write the same thing a little more compact and also creates a constructor property as well as a reference to the super constructor:

function Bar() {
}
util.inherits(Bar, Foo);
Bar.prototype.bar = function() {
  // do something else
};
Bar.prototype.baz = function() {
  // yet another method
};

Passing properties to Object.create()

Still we have to repeat Bar.prototype for each property we want to add. We can overcome this by passing a property descriptor to Object.create():

function Bar() {
}
Bar.prototype = Object.create(Foo.prototype, {
  bar: { value: function() {
    // do something else
  }},
  baz: { value: function() {
    // yet another method
  }}
});

Unfortunately this still looks quite noisy as we have to wrap all our properties into descriptor objects. On the other hand this syntax makes it easy to define getters or setters:

function Bar() {
}
Bar.prototype = Object.create(Foo.prototype, {
  bar: { value: function() {
    // do something else
  }},
  boo: {
    get: function() {
      return this._boo;
    },
    set: function(value) {
      this._boo = value && (''+value).toUpperCase();
    }
  }
});

Otherwise we’d have to call Object.defineProperty('boo', {...}) instead.

The get and set operators

Still this isn’t as concise as it could be. Since JavaScript 1.8.5 the language supports the get and set operators which can be used inside an object literal to define getters and setters:

function Foo() {
  // constructor code
}
Foo.prototype = {
  get boo() {
    return this._boo;
  },
  set boo(value) {
    this._boo = value && (''+value).toUpperCase();
  }
};

Now this is nice, but how can we use this approach for our subclass?

The deprecated, non-standard way

One possibility is to use the non-standard __proto__ property that allows us to change an objects prototype even after it has been created:

function Bar() {
}
Bar.prototype = {
  __proto__: Foo.prototype,
  get boo() {
    return 'Buh!';
  }
};

A standard based solution

Despite being deprecated the solution above is currently my favorite inheritance style. If you want to avoid using __proto__ for some reason you can write a helper function similar to Node’s util.inherits() that uses standard ECMAScript 5 features to achieve similar results:

function Foo() {
  // constructor code
}
Foo.prototype = {
  bar: function() {
    // do something
  }
};

function Bar() {
  // constructor code
}
util.prototype(Bar, Foo, {
  get boo() {
    return 'Buh!';
  }
});

Here is the implementation of the util.prototype function:

function prototype(ctor, superCtor, proto) {
  var props = {
    constructor: { value: ctor, writable: true, configurable: true }
  };
  Object.getOwnPropertyNames(proto).forEach(function(name) {
    props[name] = Object.getOwnPropertyDescriptor(proto, name);
  });
  ctor.prototype = Object.create(superCtor.prototype, props);
  ctor.super_ = superCtor;
}

TL;DR

The get/set operators are cool and __proto__ is your friend. If you don’t want to use it you can write a simple helper function to achive a similar result using standard ECMAScript features.

Brand New Blog

2012-02-15T00:00:00-08:00

Today I decided to abandon my Posterous blog and move over to GitHub Pages. The reason I chose Posterous in the first place was its Markdown support and built-in syntax highlighting. Unfortunately both features are quite cumbersome. When I wrote my last post, the syntax highlighting just didn’t work anymore. While searching for a solution I came across Paul Kinlan’s post which inspired me to try something completely different instead.

After a brief look at calepin.co and scriptogr.am I decided give jekyllbootstrap a try. It was interesting to see how much one could squeeze out of a bunch of Liquid templates and a Rakefile but like most bootstrap projects this felt a little bit bloated.

KISS

I decided to keep it simple instead and started from scratch. Since everything I blog about is usually related to a GitHub project in some way, I wanted a theme that resembled the look and feel of a GitHub project page with the same formatting as a project’s README. Especially code snippets should look exactly the same.

I stole some design elements from the official GitHub blog and made the layout responsive, so that you get a nice one-column view on mobile devices.

Another great thing about GitHub pages is that you get a decent web-based editor for free as well as a version history of your posts and the possibility to work collaboratively.