While I’m on a roll with all these Alfred posts, I figure it makes sense to get one more out. So I’m sharing my Alfred Theme.

It’s based on Wombat color scheme for Emacs from this Github gist which itself is based on a Vim color scheme created by someone named Lars Nielsen who I don’t know, but whose color scheme I’ve spent the past few years of my life staring at while building awesome things in Emacs.

Now Alfred’s wearing the same outfit.

Download my Wombat Alfred Theme

I had written a handy Extension to Alfred v1 awhile back to help me very quickly adjust my system volume with simple keyboard commands.

Well, with the release of Alfred v2, this Extension no longer worked. So I’ve now updated it as an Alfred v2 workflow.

Download it here

Commands for the v1 Extension still work, reference here

Just awesome.

Reason number 18293 that Alfred saves me a bunch of time in every day.

Alfred Dev Doctor

Long story short, Alfred 2 and Emacs installed via Homebrew don’t exactly play along nicely. Alfred 2 doesn’t like to follow symlinks so it won’t open Emacs.

For more info, see here

I had just posted on GetSatisfaction then realized that the new (awesome!) workflows would allow me to fix this myself before they intervened.

Note, this workflow assumes that you’ve installed the latest Emacs from Homebrew with the cocoa flag (24.3 as of this writing):

1

brew install emacs --cocoa

If you’ve got Emacs but the wrong version, update it with:

1
2

brew update
brew upgrade emacs --cocoa

Or simply edit my workflow and update it to use the latest path.

Download my Alfred 2 workflow here

The Problem: Microsoft and their own Cross Domain Request object

I recently came across a situation at work where I needed to do a cross domain POST on IE. We have these complex forms loaded entirely in client-side js using Backbone which we want loadable on any page but which need to submit their data directly to our API servers using CORS.

This turned out to be a non-trivial problem.

See it turns out that instead of using the XMLHttpRequest object used by jQuery or Zepto’s $.ajax(), when doing a cross domain request (such as a POST from a site served off of http://foo.com to the endpoint http://bar.com) Microsoft decided it made sense to create an entirely different request object called XDomainRequest. More details here

#comeonmicrosoft

Practically speaking, this means that neither jQuery nor Backbone work with CORS requests out of the box on IE 7, 8, and 9. Thankfully Microsoft came to their senses in IE 10 and XMLHttpRequest works fine (and so thus do jQuery and Backbone) but for earlier versions it didn’t work and sadly my company cannot yet ignore the IE populace.

The XDomainRequest functions similarly to the XMLHttpRequest object, but just different enough to be a pain.

The Solution: I created the Backbone.CrossDomain library

Our app infrastructure is all in Backbone, so I was able to write the code to handle this once and never think about it.

In my library I simply overwrote Backbone.sync which allowed the rest of our code to stay exactly the same. Things that just threw errors before on IE now just work. Like magic.

I wrote with AMD support baked in because RequireJS rocks and I tried hard to make it a drop-in replacement for the standard Backbone.sync and it still defers to Backbone.sync on every normal modern browser, but will use this XDomainRequest object when necessary.

This project is open-source and available:

On Github at https://github.com/victorquinn/Backbone.CrossDomain

and

On npm as backbone-crossdomain

Just moved from GruntJS version 0.3.x to 0.4.x so I could use some newer Grunt modules.

Most of the changes are covered well on the wiki though one odd thing I ran into was that after moving from Grunt 0.3.x to Grunt 0.4.x, the command line command “grunt” no longer worked for me. I kept getting the following error:

1

zsh: command not found: grunt

To cut a long story short, it appears in the move from Grunt 0.3.x to 0.4.x the folks who built Grunt felt it was a good idea to remove the cli piece.

I applaud this decision though I confess I glanced at the docs quickly and, at my first pass, didn’t notice that it had been stripped out. I was confused as to why I kept getting the grunt command not found when the package was clearly installed. Uninstalling 0.4.x and re-installing 0.3.x brought it back and the inverse killed it.

The solution

The solution ended up being quite easy, simply install the grunt-cli package to get the grunt command back:

1

% npm install -g grunt-cli

RequireJS site design, I love it.

It’s simple and clean and serves its purpose very well. The iconography on the left sidebar is a subtle visual indicator, having the menu static on the left side is perfect for documentation and I love the use of the monospaced Inconsolata font for headings. This is great for developer docs but then using the nice, always readable Georgia for any long format content. Anchors to each heading, enough whitespace around the content so it doesn’t feel crowded, and a great use of color on the logo. The arrow and target theme is likewise unique but not distracting.

All around top notch design.

http://requirejs.org

I recently came up against a pretty interesting problem in PHP. Explaining the problem will take up the majority of this post, the solution the minority.

If the title gives you enough info to know this is likely the solution to your problem, click here to jump to the solutions.

The Problem

On a recent application I was building in PHP, I had a parent class with children that inherited from it and overrode some methods of the parent.

I was building a queryable object, the idea of which was that I could chain together query methods which could each pass through and filter the returned dataset.

Problem being, in the parent I was returning instances of the parent class, so if I chained 2 of these together, a method called on the second call would call the parent’s method, not the child’s method (if it had overwritten the parent method).

To make this a bit more concrete, I have concocted an example which is a simplified version of the problem I needed to solve:

Example

The parent class

First, we have a filterable object class with some base methods:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<?php
class Filterable {
    protected $items;

    function __construct($i) {
        $this->items = $i;
    }

    /**
     * Limit how many items are returned
     *
     * @param $n
     *   The number of items to return
     */
    function limit($n) {
        return new Filterable(array_slice($this->get(), 0, $n));
    }

    /**
     * Skip the first N items
     *
     * @param $n
     *   The number of items to skip
     */
    function skip($n) {
        return new Filterable(array_slice($this->get(), $n));
    }

    /**
     * Return the $items as an array
     */
    function get() {
        return $this->items;
    }
}

So as you can see, a pretty simple class. It takes in an array of items and then has methods to limit() or skip() a number of items in that list and a method to get the resultant array back.

Using the Parent Class

To use this is pretty simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
$items = array (1, 2, 3, 4, 5);

// Instantiate a new instance of Filterable
$filterable = new Filterable($items);

// Now do some filtering

// Returns an object of type Filterable with the internal array
// of array(1, 2, 3, 4)
$filterable->limit(4);

// But we can also chain them

// Returns an object of type Filterable with the internal array of
// array(2, 3, 4)
$filterable->limit(4)->skip(1);

// To get the resulting array, we can use the get() function to pull out the
// internal data. So the following returns the actual array
$filterable->limit(4)->skip(1)->get();

So this is all well and good and works like a charm. Go ahead, try it, it’ll work as expected. So where does the problem arise?

Enter a child

So let’s add a child class and override one of the methods. Let’s say we want to alter the limit() function so it limits by n*2 elements if n is passed to it. It will inherit all of the attributes of the parent so there is no need to redeclare any methods we are not overriding here. So __construct(), skip(), and get() will work by using the parent’s methods.

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
class FilterableChild {

    /**
     * Skip the first N*2 elements
     *
     * @param $n
     *   Doubled, this is the number of items to skip
     */
    function skip($n) {
        return new FilterableChild(array_slice($this->get(), $n*2));
    }
}

Using this child

Let’s try using the child class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?php
$items = array (1, 2, 3, 4, 5);

// Instantiate a new instance of FilterableChild
$filterable = new FilterableChild($items);

// Now do some filtering

// Returns an object of type Filterable (note: not FilterableChild) with the
// internal array (1, 2, 3, 4)
$filterable->limit(2);

// Returns an object of type FilterableChild with the internal array (3, 4, 5)
// as it as skipped the first n*2 elements as defined in the child class
$filterable->skip(1);

// But we can also chain them

// Returns an object of type Filterable with the internal array of (2, 3, 4),
// not (3, 4) as would be expected.
$filterable->limit(4)->skip(1);

Uh oh, but that’s not what we wanted. We started off with a FilterableChild object so we’d like to call the FilterableChild object’s skip method, but we are calling the parent’s skip method here because limit() returned an object of type Filterable, not FilterableChild, so when skip() is called, the parent object’s method is called rather than the child’s.

But how to solve this? We surely do not want to update the parent to have knowledge of the child, that breaks some of the Object Oriented nature of the code.

In an ideal world we would do some kind of object introspection so the parent class would return an object of whatever type was passed to it, but PHP doesn’t really have true introspection so this will not work either!

We could use the factory pattern, but then we’d be creating a bunch of extraneous classes.

The Solutions

I actually came up with 2 solutions to this problem, one before and another while writing this article.

First solution: Messy introspection

We could use something like the following for each of our parent methods:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
class Filterable {
    ...

    /**
     * Skip the first N items
     *
     * @param $n
     *   The number of items to skip
     */
    function skip($n) {
        $myClass = get_class($this);
        return new $myClass(array_slice($this->get(), $n));
    }

    ...
}

This uses some kind of messy PHP introspection. There is no true object introspection in PHP, so the best we can do is use the get_class() method which returns a string which is the name of the class and then use that class to return an object of the type of $this.

This would obviously work for the parent, but the magic is that it also works for the child as even if the child does not implement a method (thereby falling back to the parent’s implementation) the parent will return an object of the child’s type. In other words, since $this for a child object would be FilterableChild, even if the parent’s skip() method is called, get_class($this); would return “FilterableChild” so the parent, which has no knowledge of the child is able to return an object of that child’s class.

This could also be refactored to its own member function and called from within any member methods to be a bit cleaner:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?php
class Filterable {
    ...

    /**
     * Skip the first N items
     *
     * @param $n
     *   The number of items to skip
     */
    function skip($n) {
        return $this->construct_instance_of(array_slice($this->get(), $n));
    }

    /**
     * Construct an instance matching the original class
     */
    function construct_instance_of($i) {
        $class = get_class($this);
        return new $class($i);
    }
    ...
}

This is appealing because the child class doesn’t need to do any additional work and it will work.

Second Solution: Implement construct_instance_of() in child

This solution is perhaps a bit cleaner because it doesn’t deal with the ugliness of getting the class name as a string and deaing with it, but requires any child objects to override the construct_instance_of() method to return an object of its type. Below I’ve got code for the parent and child object to make this work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
class Filterable {
    ...

    /**
     * Skip the first N items
     *
     * @param $n
     *   The number of items to skip
     */
    function skip($n) {
        return $this->construct_instance_of(array_slice($this->get(), $n));
    }

    /**
     * Construct an instance matching the original class
     */
    function construct_instance_of($i) {
        return new Filterable($i);
    }
    ...
}

1
2
3
4
5
6
7
8
9
10
11
12

<?php
class FilterableChild {
    ...

    /**
     * Construct an instance matching the original class
     */
    function construct_instance_of($i) {
        return new FilterableChild($i);
    }
    ...
}

Since an object is created with its class, if we are always using construct_instance_of() to return the object and it’s implemented in all children, the returned object will always have the child class even if the method is called from the parent.

Ugh. Just seeing the word makes me cringe. The weekend after Christmas, I moved into a new place. I am at once excited about my new home and the prospect of a new beginning while frustrated at the ridiculous time sink it has become.

Things were not (for reasons on which I will not elaborate) working out at our old place, so we packed up everything we owned and now have a fresh start in a a new townhouse.

I sit here, surrounded by boxes and bare walls, having already spent an untold number of days putting every one of my worldly possessions into those boxes just to remove them upon arrival at this new house, and knowing I’ll spend many more taking my stuff out of those boxes before reaching the end.

Things are good and I am overall quite happy, but if someone told me, “you will have to stop all work on anything productive for the next 2 months while you do nothing but pick your stuff up here and put it away on the other side” I’d have told them to shove something somewhere where things aren’t meant to shoved.

Instead of being a lot further along building Scales I have moved my stuff from over there to over here. <sarcasm>Awesome. </sarcasm>

The first few days here were exciting: - Look at all the organizing I can do! - Everything can be put in its rightful place - Clean all the things! - There are so many possibilities

But now that the honeymoon period has worn off, I’m left with a ton of boxes and little motivation. I’ve put away and dealt with the fun things, all that’s left is the tedious boring stuff. I’ll slog through it and my wife will no doubt help keep me motivated but man is it a drag.

I. Hate. Moving.

I have been following Cloud9 since their early days. I was thrilled at their open source editor, Ace (formerly Bespin) and actually wrote a Drupal WYSIWYG plugin to allow it as an option for HTML editing in Drupal.

But, when I originally looked at Cloud9, as neat as it was to be able to edit files in the cloud, it wasn’t really too useful for much.

Just recently a co-worker sent me a link to some code he had written using it with some client-side javascript code. It was nothing short of magical.

This. Changes. Everything.

Wondering what it’ll be like to develop in the future? Just try out Cloud9.

Direct git Integration

Cloud9 can pair with your Github or Bitbucket account and pull in all the code in any of your repositories. So with just the click of a button you’re up and running with your code. That’s pretty awesome.

But they actually had this awhile back when I tried it (though it now is even more fluid and awesome). What has changed?

The old problem

Code editing in the cloud was neat and all, but I had to commit any changes I made so I could check them out locally or on my webserver so I could test it and see if it blew everything up or fixed the problem I was trying to solve.

This led to a tortured workflow involving committing sometimes not working code in Cloud9, checking it out locally, running it, seeing if it worked or broke, editing and bugfixing it locally, committing that, then going back to work in Cloud9. As I’m sure you can imagine, Cloud9 quickly dropped out of my workflow and I went back to just editing everything locally.

The solution arrives!

Imagine my surprise and wonder upon most recently checking out Cloud9 when it had the ability to run code, in your browser! It can easily handle node.js, rails, I’m sure more. It even handled this Jekyll-based blog with ease! In fact I am editing this now, in Cloud9!

It has GUI shortcuts for things like git commands, npm install/uninstall, and more, but it also allows you to drop directly into a terminal and run commands there! It’s just like having your own server with none of the headache.

Always in sync across systems

One of my favorite benefits of this approach is that everything is, by its nature always in sync across systems. I can pick up my laptop, do some work, then move to my desktop, open Cloud9 and everything is just as I left it. I could go sit down in a random computer lab or library and still be in sync and ready to roll.

This last bit, in my opinion, is the most powerful feature of this kind of Cloud programming. For $0, I can have an always in sync IDE operable from any browser, my own cloud server, and more. It took awhile for the gravity of this to sink in, but this is pretty amazing. The barrier to entry for programming with a server has never been lower

Conclusion

There’s a lot more to discuss that I’m not touching on here, just wanted to hit some of the quick highlights. I’m trying to work this into my workflow more so I’m sure I’ll have more thoughts later.

This is seriously awesome and feels like the future…