Over the next two years, I bounced from project to project, started running, tried several diets, read a bunch of books on music and philosophy and meditated frequently. I flirted with Musicology, and later, Music Journalism. I started writing in-depth music reviews and posted them to my blog. I was accepted into NYU for a self-designed degree in music scholarship, but the cost was prohibitive. I couldn’t stay in Cleveland as my friends all graduated and left. I left for Austin a month later, to start over from scratch.

In December 2013, I was looking over my roommate’s shoulder at his solutions to Project Euler problems, written in JavaScript. It looked exciting. I recalled making rudimentary websites in Junior High, before music completely took over my life. I picked up a little Ruby and started from Problem 1...

Finding a second passion is different than the first. I had been here before and was guarded against the waning interest that had smothered every previous endeavor. But I kept going, picking up JavaScript, CSS, and enough PHP to power through a WordPress theme for my blog. The learning curve was exhilarating and it wasn’t stopping. I subscribed to countless blogs on web design and development and I actually read them. I was becoming more savvy, started getting real Twitter followers and stars on GitHub. I fashioned my music blog into one about web development, and people were interested in what I was writing. I couldn’t believe it. After so long projecting my passions into the world, finally one responded. I was falling in love with the web.

Over 4 years have passed since I dropped out of conservatory. But I have found myself a new mountain with an even higher summit and people there cheering me on. I am lucky to have stumbled blindly into this profession that is so full of vitality, and I am proud of and humbled by my experience so far. When I left the classical music world, I took a dive into the unknown. My only insurance was my own resolve. Like the opening to the William Tell Overture, a lone cello projecting into the silence, awaiting its symphony.

Sincerely,
Evan

You can find the complete original and refactored code on GitHub.

The Original

The original code uses Webpack's require.ensure API directly. By design, require.ensure cannot work with dynamic module paths, which leads to a lot of repetitive code (the React Router team split this code into tree of route files). Because of this limitation, routing logic is now scattered throughout the routes folder at various depths, and a commented representation of the routes is necessary to understand what's going on at a glance. The src/ directory looks like this:

├── components
├── routes
│   ├── Calendar
│   │   ├── components
│   │   │   └── Calendar.js
│   │   └── index.js
│   ├── Course
│   │   ├── components
│   │   │   ├── Course.js
│   │   │   ├── Dashboard.js
│   │   │   └── Nav.js
│   │   └── routes
│   │       ├── Announcements
│   │       │   ├── components
│   │       │   │   ├── Announcements.js
│   │       │   │   ├── Sidebar.js
│   │       │   ├── routes
│   │       │   │   └── Announcement
│   │       │   │       ├── components
│   │       │   │       │   └── Announcement
│   │       │   │       └── index.js
│   │       │   └── index.js
│   │       ├── Assignments
│   │       │   ├── components
│   │       │   │   ├── Assignments.js
│   │       │   │   ├── Sidebar.js
│   │       │   ├── routes
│   │       │   │   └── Assignment
│   │       │   │       ├── components
│   │       │   │       │   └── Assignment
│   │       │   │       └── index.js
│   │       │   └── index.js
│   │       └── Grades
│   │           ├── components
│   │           │   └── Grades.js
│   │           └── index.js
│   ├── Grades
│   │   ├── components
│   │   │   └── Grades.js
│   │   └── index.js
│   ├── Messages
│   │   ├── components
│   │   │   └── Messages.js
│   │   └── index.js
│   └── Profile
│       ├── components
│       │   └── Profile.js
│       └── index.js
├── stubs
└── app.js

We can do better than that.

The Refactor

We can use Webpack's own bundle-loader to get around the limitations of raw require.ensure and greatly simplify our code. Bundle loader abstracts away the require.ensure logic that bloated and obscured our code. When a module is run through bundle-loader, a chunk will be created for it and its dependencies, and a function wrapper is returned instead of the original module. When the function wrapper is invoked, it will ajax in the module and pass it to a callback function.

We can eliminate all of the index.js files througout the routes/ directory and flatten the structure where it makes sense. All of our routing logic will be moved to app.js. This results in a massively simplified src/ directory:

├── components
├── routes
│   ├── Calendar.js
│   ├── Course
│   │   ├── components
│   │   │   ├── Dashboard.js
│   │   │   └── Nav.js
│   │   ├── routes
│   │   │   ├── Announcements
│   │   │   │   ├── routes
│   │   │   │   │   └── Announcement.js
│   │   │   │   ├── Announcements.js
│   │   │   │   └── Sidebar.js
│   │   │   ├── Assignments
│   │   │   │   ├── routes
│   │   │   │   │   └── Assignment.js
│   │   │   │   ├── Assignments.js
│   │   │   │   └── Sidebar.js
│   │   │   └── Grades.js
│   │   └── Course.js
│   ├── Grades.js
│   ├── Messages.js
│   └── Profile.js
├── stubs
└── app.js

Once we've updated the file structure, we can direct webpack to run route components through bundle-loader. Since we don't want to split every single file in routes/ (specifically the files in components/ directories), we will need to write a regex to match the right files. In this particular app, we know route components are any files matching routes/*.js or routes/SOMETHING/*.js. Any files matching routes/SOMETHING/components/*.js should NOT be included:

// NOTE: this assumes you're on a Unix system. You will
// need to update this regex and possibly some other config
// to get this working on Windows (but it can still work!)
var routeComponentRegex = /routes\/([^\/]+\/?[^\/]+).js$/  

module.exports = {  
  // ...rest of config...
  modules: {
    loaders: [
      // make sure to exclude route components here
      {
        test: /\.js$/,
        include: path.resolve(__dirname, 'src'),
        exclude: routeComponentRegex,
        loader: 'babel'
      },
      // run route components through bundle-loader
      {
        test: routeComponentRegex,
        include: path.resolve(__dirname, 'src'),
        loaders: ['bundle?lazy', 'babel']
      }
    ]
  }
  // ...rest of config...
}

Now, in app.js, we can simply import our route components like normal:

// Webpack is configured to create ajax wrappers around each of these modules.
// Webpack will create a separate chunk for each of these imports (including
// any dependencies)
import Course from './routes/Course/Course'  
import AnnouncementsSidebar from './routes/Course/routes/Announcements/Sidebar'  
import Announcements from './routes/Course/routes/Announcements/Announcements'  
import Announcement from './routes/Course/routes/Announcements/routes/Announcement'  
import AssignmentsSidebar from './routes/Course/routes/Assignments/Sidebar'  
import Assignments from './routes/Course/routes/Assignments/Assignments'  
import Assignment from './routes/Course/routes/Assignments/routes/Assignment'  
import CourseGrades from './routes/Course/routes/Grades'  
import Calendar from './routes/Calendar'  
import Grades from './routes/Grades'  
import Messages from './routes/Messages'  

As mentioned earlier, these are not the route components themselves, but function wrappers that will load the correct chunk when called.

We will need to use React Router's route.getComponent to load these chunks asynchronously. First, we must set up a function which recieves the ajax wrapper, and returns a function which will load the module when the route is requested:

function lazyLoadComponent(lazyModule) {  
  return (location, cb) => {
    lazyModule(module => cb(null, module))
  }
}

Since this project uses route.getComponents as well, we will need another function:

function lazyLoadComponents(lazyModules) {  
  return (location, cb) => {
    const moduleKeys = Object.keys(lazyModules);
    const promises = moduleKeys.map(key =>
      new Promise(resolve => lazyModules[key](resolve))
    )

    Promise.all(promises).then(modules => {
      cb(null, modules.reduce((obj, module, i) => {
        obj[moduleKeys[i]] = module;
        return obj;
      }, {}))
    })
  }
}

Now, your routes can be defined all at once as JSX:

render(  
  <Router history={ browserHistory }>
    <Route path="/" component={ App }>
      <Route path="calendar" getComponent={ lazyLoadComponent(Calendar) } />
      <Route path="course/:courseId" getComponent={ lazyLoadComponent(Course) }>
        <Route path="announcements" getComponents={ lazyLoadComponents({
          sidebar: AnnouncementsSidebar,
          main: Announcements
        }) }>
          <Route path=":announcementId" getComponent={ lazyLoadComponent(Announcement) } />
        </Route>
        <Route path="assignments" getComponents={ lazyLoadComponents({
          sidebar: AssignmentsSidebar,
          main: Assignments
        }) }>
          <Route path=":assignmentId" getComponent={ lazyLoadComponent(Assignment) } />
        </Route>
        <Route path="grades" getComponent={ lazyLoadComponent(CourseGrades) } />
      </Route>
      <Route path="grades" getComponent={ lazyLoadComponent(Grades) } />
      <Route path="messages" getComponent={ lazyLoadComponent(Messages) } />
      <Route path="profile" getComponent={ lazyLoadComponent(Calendar) } />
    </Route>
  </Router>,
  document.getElementById('example')
)

That's it! We've eliminated a ton of files and boilerplate code with one webpack loader.

Server Rendering

Since Webpack only creates these Ajax wrappers for the client bundle, you will need to make sure the server requires the files synchronously. This can be handled by adding a little function and using it in place of lazyLoadComponent():

function loadComponent(module) {  
  return __CLIENT__
    ? lazyLoadComponent(module)
    : (location, cb) => cb(null, module);
}

All universal apps need some sort of global which allows you to check whether the code is running on the client or the server. This function will immediately resolve the module normally on the server and lazy load the element on the client. It's as simple as that!

What does it take to go from this:

// mock async function
function incrementAsync(n, cb) {  
    setTimeout(function() {
        cb(n + 1);
    }, 100);
}

var n0 = 1;

incrementAsync(n0, function(n1) {  
    incrementAsync(n1, function(n2) {
        incrementAsync(n2, function(n) {
            console.log(n); // => 4
        });
    });
});

To this?

// wrap incrementAsync() and return a promise
var incrementAsyncPromise = function(n) {  
    var promise = pinkyPromise();

    incrementAsync(n, function(ret) {
        promise.resolve(ret);
    });

    return promise;
};

var n0 = 1;

incrementAsyncPromise(n0)  
    .then(incrementAsyncPromise)
    .then(incrementAsyncPromise)
    .then(function(n) {
        console.log(n); // => 4
    });

Or, even better, to this?

var incrementAsyncPromise = pinkyPromise(incrementAsync);

var n0 = 1;

incrementAsyncPromise(n0)  
    .then(incrementAsyncPromise)
    .then(incrementAsyncPromise)
    .then(function(n) {
        console.log(n); // => 4
    });

45 Lines of Code

Step 1

We’ll need pinkyPromise() to return an object with two methods: .then and .resolve.

function pinkyPromise() {  
    return {
        then: function() {},
        resolve: function() {}
    };
}

Step 2

Every time .then is called, push the callback into a queue and return the same object.

function pinkyPromise() {  
    var queue = [];

    return {
        then: function(cb) {
            if (cb) {
                // add cb to queue
                queue.push(cb);
            }
            return this;
        },
        resolve: function() {}
    };
}

That's already 14 lines. Almost a third of the way there!

Step 3

Set up your resolve function to accept a single parameter: the value to return.

function pinkyPromise() {  
    var queue = [];

    function resolve(ret) {

    }

    return {
        then: function(cb) {
            if (cb) {
                // add cb to queue
                queue.push(cb);
            }
            return this;
        },
        resolve: resolve
    };
}

Step 4

There are three scenarios that could happen when .resolve is called.

1. There are no more callbacks to resolve, in which case, just return.
2. ret is a promise.
3. ret is not a promise.

function pinkyPromise() {  
    var queue = [];

    function resolve(ret) {
        if (!queue.length) {
            return;
        } else if (ret && ret.then) {
            // ret is a promise
        } else {
            // ret is not a promise
        }
    }

    return {
        then: function(cb) {
            if (cb) {
                // add cb to queue
                queue.push(cb);
            }
            return this;
        },
        resolve: resolve
    };
}

24 lines! This is where it gets fun.

Step 5

If ret isn't a promise, then lets send it to the oldest callback and resolve the new return value.

function pinkyPromise() {  
    var queue = [];

    function resolve(ret) {
        if (!queue.length) {
            return;
        } else if (ret && ret.then) {
            // ret is a promise
        } else {
            // ret is not a promise
            var newRet = queue.shift()(ret);
            resolve(newRet);
        }
    }

    return {
        then: function(cb) {
            if (cb) {
                // add cb to queue
                queue.push(cb);
            }
            return this;
        },
        resolve: resolve
    };
}

Step 6

If ret is a promise, then we'll call its then method and resolve within the same scope!

function pinkyPromise() {  
    var queue = [];

    function resolve(ret) {
        if (!queue.length) {
            return;
        } else if (ret && ret.then) {
            // ret is a promise
            ret.then(resolve);
        } else {
            // ret is not a promise
            var newRet = queue.shift()(ret);
            resolve(newRet);
        }
    }

    return {
        then: function(cb) {
            if (cb) {
                // add cb to queue
                queue.push(cb);
            }
            return this;
        },
        resolve: resolve
    };
}

Step 7

The following is now possible:

var incrementAsyncPromise = function(n) {  
    var promise = pinkyPromise();

    incrementAsync(n, function(ret) {
        promise.resolve(ret);
    });

    return promise;
};

But I want to be able to simply pass in incrementAsync rather than explicitly wrap it. Since most async functions accept the callback as the final argument, we can abstract the above into a function called promisify. We'll allow a fn argument to be passed into pinkyPromise, and instead of returning the promise object, we'll return the promisified function:

function pinkyPromise(fn) {  
    var queue = [];

    function promisify(fn) {
        // converts fn w/ callback to return promise
        return function() {
            var promise = pinkyPromise();
            var args = Array.prototype.slice.call(arguments);

            // add promise.resolve as final argument
            args.push(promise.resolve);

            fn.apply(this, args);

            return promise;
        };
    }

    function resolve(ret) {
        if (!queue.length) {
            // no more callbacks
            return;
        } else if (ret && ret.then) {
            // ret is a promise
            ret.then(resolve);
        } else {
            // ret is not a promise
            var newRet = queue.shift()(ret);
            resolve(newRet);
        }
    }

    // if fn, return promisified fn
    // otherwise return a promise
    return fn ? promisify(fn) : {
        then: function(cb) {
            if (cb) {
                // add cb to queue
                queue.push(cb);
            }
            return this;
        },
        resolve: resolve
    };
}

That's it!

Congratulations! You've just solved Callback Hell™ with straight up functional programming prowess.

Check it out on GitHub.

If you're interested in a more thorough look at promises, Matt Greer's JavaScript Promises...In Wicked Detail was extremely helpful as I was beginning to wrap my head around them. He goes into much, much more detail, including rejecting promises. Highly recommended.

Also check out James Coglan's very insightful article Callbacks are imperative, promises are functional: Node’s biggest missed opportunity.

Facebook doesn’t provide a framework for Flux, only how to make one from scratch. So I began searching for implementations. Surprisingly, there are already a few good (though somewhat poorly-named) options: jFlux, Fluxy, Fluxxor, and finally, Reflux. Of them, Reflux appeared to have the most backers and the most elegant API. I was also won over by Krawaller’s explanations of the overarching philosophy behind Reflux and how using Reflux can dramatically simplify a Flux application.

Reflux has a small and simple codebase of around 13kb minified. The API is clearly defined and often highly intuitive. It took me some time to acclimate to the “Flux way” of thinking, during which I found that old ways of thinking can get you into frustrating situations. Luckily, considering the age of Flux, there are a lot of resources available. Throughout the process of building my app, I found Krawaller’s posts, Facebook's overview of Flux, and the solid Reflux README to be indispensable references.

Over the past month, I’ve been hacking away at a Reddit-like demo app using React+RefluxJS+Firebase, and while it’s still a work in progress, I think it’s turning out to be quite a good looking project. Here’s what I learned.

What I Learned

One Store, One Component

Initially, I thought that I should create a Store for each type of data: userStore, postStore, and commentStore. This doesn’t work well in Reflux. Unlike other Flux implementations, Reflux publishers (Actions and Stores) can only ever emit one type of event. It’s possible to use Actions to persuade a Store to emit different data, but it’s unnecessarily difficult to orchestrate. It also makes stores more difficult to test. This is an intentional limitation of Reflux. By removing name strings from events, Reflux eliminates the need for a global dispatcher, drastically simplifying application data flow.

This problem is better solved by separating Stores by component rather than data type. In React News, I have a Store for each view (singleStore, postsStore, and profileStore), one for the login form (loginStore). I kept the userStore, but it is exclusively syced to my top level component and user data is passed down via props.

Since Stores are only supposed to emit one type of event, there are not many reasons for multiple components to listen to the same Store. But there are some exceptions. In addition to my top level component, my login component also needs to know when a login event fires so it can reset its form. The data doesn’t matter, only that the event fired. It can safely listen for an update from userStore and then reset its form.

var Login = React.createClass({

    mixins: [Reflux.listenTo(userStore, 'resetForm')],

    resetForm: function() {
        this.setState({
            submitted: false,
        });
        this.refs.email.getDOMNode().value = '';
        this.refs.password.getDOMNode().value = '';
        this.refs.submit.getDOMNode().disabled = false;
    },

    // etc...
});

Single File For Actions

Similarly to Stores, I tried splitting my Actions into separate files: userActions, postActions, and commentActions. But I found that sometimes a postAction would need to call a commentAction, or vice versa, and circular dependencies started happening. So I moved all of my Actions into one file and that was that.

Actions calling Actions vs. Stores calling Actions vs. Stores calling Stores

In the real world, sometimes Actions need to be fired once an async request completes. There is a discussion to be had about whether it’s kosher to initiate an Action from a Store, say, right before it triggers, or if it’s better to move API requests to the Action’s .preEmit() method and call other Actions from there. I prefer the latter, as it better maintains one-directional data flow:

actions.addComment.preEmit = function(comment) {  
    commentsRef.push(comment, function(error) {
        if (error === null) {
            actions.updateCommentCount(comment.postId, 1);
        }
    });
};

Flexibility in the Reflux PubSub Model

As Krawaller states in The Reflux data flow model:

At its heart, Reflux is really just a PubSub library. That is, we have a Publisher API for objects who transmit events, and a Subscriber API for objects who want to listen to such events.

The fact that any Subscriber can listen to any Publisher means there is some degree of flexibility. This flexibility is sometimes convenient: for simple UI events, rather than passing props down several component layers or creating another Store, I just use an Action:

var SinglePost = React.createClass({

    addComment: function(e) {
        e.preventDefault();

        if (!this.props.user.isLoggedIn) {
            actions.showLoginOverlay();
            return;
        }

        // submit comment...
    },

    // render, etc...

});

And at the top level, I can listen to the Action directly:

var ReactNews = React.createClass({

    mixins: [
        Reflux.listenTo(actions.showLoginOverlay, 'showLoginOverlay')
    ],

    showLoginOverlay: function() {
        this.setState({
            showOverlay: true
        });
    }

    // etc...
});

If it were any more complex, I might rather move all this state to a Store, but for my needs, this is sufficient.

Summing Up

Reflux recently reached v0.2.0, but it’s already a powerful tool for building Flux applications. For those who are looking for examples of Reflux applications, you’re welcome to check out my code on GitHub. The live demo is available here.

You can log in with:
Email: reactnews@example.com
Password: henleyedition1

This is still a work in progress, so sorry for any bugs! The full source is available on my github. Click below to play!

By default, React uses a XML-like syntax called JSX, which has already been compiled to plain JavaScript below. You can view the original, uncompiled source on GitHub.

See the Pen ijLyp by Evan Henley (@echenley) on CodePen.

JavaScript itself is conflicted about its prototypal nature. In a prototypal system, objects inherit from objects. JavaScript, however, lacks an operator that performs that operation. Instead it has a new operator...Prototypal Inheritance in JavaScript, Douglas Crockford

The goal is to create a new object with a given prototype link. The status quo goes something like this:

function Person(name) {  
    this.name = name;
}

Person.prototype = { species: 'human' };

var finn = new Person('Finn');  
console.log(finn);          // { name: 'Finn' }  
console.log(finn.species);  // human

var fiona = new Person('Fiona');  
console.log(fiona);         // { name: 'Fiona' }  
console.log(fiona.species); // human  

See that fancy new operator? If you aren't already familiar with it, good luck understanding what's going on here. What does this refer to? What does Person() return? What is this prototype property that's added to Person and how is finn linked to it?

The pattern for creating objects with the new operator has always seemed really strange to me, like all the rules of JavaScript are suddenly suspended. A bunch of magic happens and poof—you've got yourself an object and somehow Person.prototype is its prototype. Wait, what? No wonder people are confused about prototypal inheritance—none of it is ever explicitly coded!

This indirection was intended to make the language seem more familiar to classically trained programmers, but failed to do that, as we can see from the very low opinion Java programmers have of JavaScript.Prototypal Inheritance in JavaScript, Douglas Crockford

The reality is that this paradigm sucks, and there's a better way to create objects with much less magic.

ECMAScript 5 (released in 2009) made Object.create() available as an alternative to the new syntax. You pass it any object (we'll call ours personProto) and it returns a new object with personProto as its prototype. The new confusion is no longer necessary; we can rename Person() to the more descriptive newPerson() and lose the this:

var personProto = { species: 'human' };

function newPerson(name) {  
    var person = Object.create(personProto);
    person.name = name;
    return person;
}

var finn = newPerson('Finn');  
console.log(finn);          // { name: 'Finn' }  
console.log(finn.species);  // human

var fiona = newPerson('Fiona');  
console.log(fiona);         // { name: 'Fiona' }  
console.log(fiona.species); // human  

Ah, suddenly it all makes sense! You define a function that when called creates an object with a specified prototype, assigns that object whatever properties you want, and finally returns it. It does the exact same thing as the first example, except without the hand-waving. This is essentially a native and better-looking implementation of Crockford's abstraction:

function object(o) {  
    function F() {}
    F.prototype = o;
    return new F();
}

It takes an old object as a parameter and returns an empty new object that inherits from the old one. If we attempt to obtain a member from the new object, and it lacks that key, then the old object will supply the member. Objects inherit from objects. What could be more object oriented than that?Prototypal Inheritance in JavaScript, Douglas Crockford

Browser compatibility is actually pretty great at this point. If you need to support legacy browsers, you can include an ES5 shim.

I don't know what this means for new, if it is going obsolete or if there's some important use-case I'm overlooking. The least you can say is that Object.create() is a good addition to the language, and a reaffirmation of JavaScript's simple, prototypal nature.

Sometimes Hijax is referred to as "Ajaxing" or "Ajaxifying", but these are less specific terms. It's important from the start to understand that Hijax is a specific variety of Ajax, and thus the two terms are not strictly interchangeable. I will explain both over the course of this article.

I am not the first to fall victim to the siren song of Ajax. In 2011, an older style of Hijax Ajax called "Hashbang URLs" brought down Gawker, who were just trying to be cool. Similarly, I realized during my most recent project that I, too, was in over my head, spending more time constructing stopgaps to ensure that arbitrary third-party plugins would work than I was spending on anything else.

Maybe you've been there and you're familiar with the perils. Maybe not. Either way, before you begin steering your ship towards Sirenum ajaxuli, let my experience serve as a warning: strap yourself to the mast and consider the cons of Ajaxing your WordPress theme.

What is Ajax?

For those who aren't familiar with it, Ajax is a simple but powerful (and increasingly common) front-end technique in which JavaScript makes a server request in the background. Then, instead of loading a whole new page, the server returns its data to the JavaScript, which can process it or load it into the DOM. Meanwhile, the client can continue without interruption. Ajax is like sending the intern to Starbucks so you can keep working.

So, if Ajax allows for an uninterrupted browsing experience, why don't developers use it for everything? Well, it turns out that Ajax does have its share of consequences depending on what you're trying to accomplish. Ultimately for this project, three major issues caused me to renege on full-site Hijax in favor of a more targeted approach.

Issue #1 - Specific information is hard to come by

Stick some combination of "ajaxify"/"ajax"/"hijax" into the search bar and you'll quickly discover that there's no standardized terminology for any of this, meaning even if there is pertinent information out there, you'll never find it beneath heaps of articles about plugins and forms and whatever else. Maybe I'm naive, but WordPress' native implementation of Ajax shows up in search results so consistently that I began to question my understanding that it was irrelevant (it was) and wasted a bunch of time as a result.

Yes, it turns out that Ajax has tons of uses, and adding sex-appeal via Hijax is just one of them. A couple common uses are form validation, shopping carts, and saving drafts on the fly, but really, Ajax can be considered for anything where you need to swap data asynchronously between client and server.

The side effect of its broad appeal is that it's sort of difficult to find the right information for the right kind of Ajax. Specifically, good information on how to properly implement Hijax is surprisingly lacking, which brings me to my next point...

Issue #2 - What information there is, is obsolete

Ajax is a burgeoning and rapidly changing paradigm in web development. When you do find Hijax-relevant resources, even from a year or two ago, you have to be careful of out of date information. For the basics, CSS-Tricks has a great screencast on "Ajaxing" a WordPress theme.

Unfortunately it's from 2010 and uses the outdated "hashbang" or fragment identifier technique that was fashionable at the time (the same one that got Gawker in trouble). You'll find plenty of articles on this technique, but it's pretty flawed, and nowadays there's a better alternative in the modern History API, which does all the good stuff without breaking the internet.

Luckily, it is fairly easy to adapt the CSS-Tricks code to use it. You will still need to provide a fallback for browsers that don't support the History API (IE9), but since you're not cutting up URLs, that's as simple as a redirect:

if (typeof history.pushState === 'undefined') {  
    // Refresh the page to the new URL if pushState not supported
    location.href = url;
}

So as you start massaging that code into your theme, you suddenly realize...

Issue #3 - All your JavaScript widgets and plugins don't work anymore

Honestly, implementing Hijax isn't that difficult, even without a library like jQuery. The problem lies in the fact that managing JavaScript and CSS resources becomes much more difficult when your site runs on Ajax.

Many WordPress plugins count on specific JavaScript being executed when the page is loaded, but Ajax throws a wrench into that. Unless you have full control over what users can and cannot add to their site (hahaha), you're going to have to resort to one of two options:

Option 1 - Specifically add code to reload known widgets. The operative word being "known". On Henley Edition, I use something like this:

glassApp.pageSetup.reload = function() {  
    // do all the normal page setup
    glassApp.pageSetup.init();
    // re-scan for code blocks
    Prism.highlightAll();
};

Option 2 - Hack something together to parse the GET data for script tags and execute them manually, which just sounds like an awful idea from the get-go. You might be tempted to do really gross things that will almost certainly get you into trouble. Maybe store loaded resources in an array so as not to load the same script/stylesheet more than once? You might also need to remove certain scripts from page to page, lest your site crumple to its knees.

If you're a tricky son of a gun, you might be able to make it work, but you can see we're not in Kansas anymore. It was around this point that I began questioning whether this enhancement was really worth the hassle.

Summing up

Moral of the story: don't try to add Hijax to a public WordPress theme. Because third-party scripts generally need to be hard-coded into the theme for Hijax to work properly, compatibility with JavaScript plugins is pretty limited.

If you do have control, though, I say go for it. The responsiveness of a well-tailored Ajax-driven website is a wonderful thing, and once you know when to use it, you'll want to implement it in every project.

// allow command-click and control-click to open new tab
if (event.metaKey || event.ctrlKey) {  
    return;
} else {
    event.preventDefault();
}

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

The statement is an instance of recursion, where an object contains a reference to itself. Throughout G.E.B., Hofstadter outlines a theory in which consciousness is the inevitable result of "strange loops"—or complex, hierarchical, recursive structures—happening within our own brains.

Recursion can clearly have humorous qualities. A hidden punchline, for instance. In a nod to Hofstadter, Randall Munroe of XKCD created:

I'm So Meta, Even This Acronym

The powerful nature of recursion has been known to mathematicians for hundreds of years. Take for example the equation:

$f_n = f_{n-1} + f_{n-2}$

If we let $f_0 = 1$ and $f_1 = 1$, this equation renders the Fibonacci sequence, a mathematical concept that has fascinated artists, scientists and mathematicians for ages, and which is found over and over again in nature.

$f_0 = 1$
$f_1 = 1$
$f_2 = f_0 + f_1 = 1 + 1 = 2$
$f_3 = f_1 + f_2 = 1 + 2 = 3$
$f_4 = f_2 + f_3 = 2 + 3 = 5$

The beauty of recursive structures lies in the disconnect between their simplicity and their extraordinary power. Take for instance the Mandelbrot set, a manifestation of a simple recursive equation:

$z_{n+1} = z_n^2 + c$

It seems easy enough for Fibonacci, but things can quickly get out of hand when trying to construct a recursive algorithm. In computer science education, programmers are taught not only to understand recursion, but also to "trust" it. Attempting to trace the logic down more than a couple levels will lead ultimately to madness. Our job as programmers is simply to set up the scaffolding, and trust that if it works for simple input, then it should work for more complex input.

Let's try an example from Project Euler.

The Problem

In England the currency is made up of pound, £, and pence, p, and there are eight coins in general circulation:

1p, 2p, 5p, 10p, 20p, 50p, £1 (100p) and £2 (200p).

It is possible to make £2 in the following way:

1×£1 + 1×50p + 2×20p + 1×5p + 1×2p + 3×1p

How many different ways can £2 be made using any number of coins?

Plan of Attack

How would you go about solving this problem without a computer? Most of the time, if you can think of a systematic way of doing it manually, you can make the computer do it for you.

To make the problem more managable, let's see if we can make something work with just three coins: 200p (2£), 100p (1£), and 50p.

Recursion is not just an abstract concept; we use it naturally all the time in problem solving. In fact, one of the most natural ways of solving this problem is actually recursive. I set it up here with nested lists to show the logic visually. We'll work our way down from the highest value coin (200p) to the lowest (50p).

Imagine you have a bowl of coins in front of you.

1. Take a 200
   
   1. Subtotal (200) = 200
   2. Add 1 to combos (0+1=1), go back
2. Take a 100
   
   1. Subtotal (100) < 200
   2. Take a 100
      1. Subtotal (200) = 200
      2. Add 1 to combos (1+1=2), go back
   3. Take a 50
      1. Subtotal (150) < 200
      2. Take a 50
         1. Subtotal (200) < 200
         2. Add 1 to combos (2+1=3), go back
      3. No more smaller coins, go back
   4. No more smaller coins, go back
3. Take a 50
   
   1. Subtotal (50) < 200
   2. Take a 50
      1. Subtotal (100) < 200
      2. Take a 50
         1. Subtotal (150) < 200
         2. Take a 50
            1. Subtotal (200) = 200
            2. Add 1 to combos (3+1=4), go back
         3. No more smaller coins, go back
      3. No more smaller coins, go back
   3. No more smaller coins, go back
4. No more smaller coins
5. Total = 4

Notice how at each level of depth, we are applying the exact same rules as the level above it. That is recursion!

The Solution

Though we'll be going through it step by step in this post, the truth is that programming is never a straightforward task. You will be jumping from one section of code to the other. Getting everything to work together requires a lot of tinkering, and tinkering takes time.

So here is the complete javascript program we're building. Take a look and see if you can understand how it all works together.

var coins = [200,100,50,20,10,5,2,1],  
    target = 200,
    combos = 0;

function add_coin(coin,subtotal) {  
    var sub_combos = 0;
    subtotal += coins[coin];
    if (subtotal > target) return 0;
    if (subtotal === target) return 1;
    for (var c = coin; c < coins.length; c++) {
        sub_combos += add_coin(c,subtotal);
    }
    return sub_combos;
}

for (var c = 0; c < coins.length; c++) {  
    combos += add_coin(c,0);
}

console.log(combos);  

Breaking It Down

First we'll set up an array of coins, the target value (200p) and a variable to hold the number of combinations we end up with.

var coins = [200,100,50,20,10,5,2,1],  
    target = 200,
    combos = 0;

We start by choosing each starting coin in succession, from highest value to lowest. We then call the function add_coin(), which returns the number of sub-combinations using each starting coin and add that value to combos. We have to send the function two parameters: (1) the current coin, and (2) the current subtotal. Since we are adding the first coin, the subtotal is 0.

for (var c = 0; c < coins.length; c++) {  
    combos += add_coin(c,0);
}

Next, we'll set up a function which will systematically add coins one at a time, and eventually return the number of sub-combinations for that starting coin.

function add_coin(coin,subtotal) {  
    var sub_combos = 0;
    subtotal += coins[coin];

    // check the subtotal against the target
    // return 0 if we go over, or a 1 if we hit the target
    if (subtotal > target) return 0;
    if (subtotal === target) return 1;

    // we're below the target, so choose next coin
    for (var c = coin; c < coins.length; c++) {
        // call add_coin() again and add the result to sub_combos
        sub_combos += add_coin(c,subtotal);
    }
    // return the accumulated sub_combos once all coins have been tried
    return sub_combos;
}

• sub_combos - holds the running total of sub-combinations in the current instance of add_coin()
• subtotal - keeps track of the value of our current set of coins.

It's important to understand that each instance of add_coin() has its very own sub_combos, which doesn't interact with any other level until it is returned.

Basically what is happening is that each time add_coin() is called, a new sub_combos is set up and the value of the new coin is added to subtotal. Unless subtotal matches or exceeds the target, it will call add_coin() again. When the target is reached, it will return a value to the level above it, increment that level's sub_combos and continue the process with the next coin, until all levels run out of smaller coins and return cascading to the top.

You can see here that we're only ever adding 1 to sub_total. That means that whatever the output is (SPOILER: it's 73682), add_coin() must have run at least that many times!

Another interesting thing to note is that since the function only adds a single coin, the number of coins you currently have is the same as the number of levels deep into the recursion you are. Since the maximum number of coins is 200 (200x1p), the program will go 200 levels deep!

The Origin of Complexity

An algorithm is like a piece of music. In the same way that great music has not a note too many, beautiful algorithms are short and stylish. Recursion is a way to cheat, almost, a way to do more than you should be able to. The fact that meaningful recursion even exists can boggle the mind.

Boggling though it is, recursion is a fundamental mechanism of life itself. The origin of complexity. To go from sprout to spruce, you don't need DNA for every branch. You just need the right equation.

So when I'm building a recursive algorithm, I can't help but feel like I'm doing something really sneaky, like I'm stealing a tool from nature's toolshed, which, if my logic is sound, makes me Prometheus, and nature? Well, I'm sure nature has something in store for me.

Table of contents

• Headings
• Text
• Blockquotes
• Lists
• Media
• Syntax Highlighting
• Tables
• Helper Classes

Headings

In Scratch, <h1> tags are reserved for site and post titles. They do not have any special formatting.

## Heading Text

Sustainable Helvetica food truck, 3 wolf moon beard Truffaut art party McSweeney's raw denim banjo Kickstarter disrupt freegan four loko.

### Heading Text

Master cleanse cray next level, art party Bushwick skateboard High Life meh drinking vinegar squid kogi letterpress quinoa.

#### Heading Text

Butcher asymmetrical sriracha, meh kale chips Bushwick narwhal food truck.

##### Heading Text

Blue Bottle banjo drinking vinegar, mustache next level organic American Apparel photo booth cardigan.

###### Heading Text

Freegan master cleanse farm-to-table, street art pug Odd Future disrupt typewriter Cosby sweater wolf Banksy actually Thundercats.

Text

This is a paragraph. Some sentences are bolded. Some are italicized. You can even add inline code blocks by using backticks `<p>code block</p>` in the markdown editor. Inline links like this one can be added using [text](http://the-url.com). Scratch supports more HTML tags than you'll ever need.

Markdown

This is a paragraph. **Some sentences are bolded**. _Some are italicized_. You can even add inline code blocks by using backticks `` `<p>code block</p>` `` in the markdown editor. Inline links [like this one](#) can be added using `[text](http://the-url.com)`. Scratch has support for more html tags than you'll ever think to use.

Blockquotes

Normal Blockquote

Banksy Schlitz deep v, cred selfies artisan semiotics Austin PBR biodiesel mlkshk retro kitsch. Tofu readymade Cosby sweater paleo Wes Anderson Williamsburg, cliche deep v viral four loko next level meggings tousled. You probably haven't heard of them hella flexitarian, Marfa meh kitsch iPhone jean shorts.

Markdown

> Banksy Schlitz deep v, cred selfies artisan semiotics Austin PBR biodiesel mlkshk retro kitsch. Tofu readymade Cosby sweater paleo Wes Anderson Williamsburg, cliche deep v viral four loko next level meggings tousled. You probably haven't heard of them hella flexitarian, Marfa meh kitsch iPhone jean shorts.

Pullquote

Austin 8-bit Schlitz, occupy bespoke leggings fashion axe cliche literally American Apparel trust fund craft beer fap shabby chic. Wayfarers synth typewriter, shabby chic before they sold out squid put a bird on it gentrify ethical.

Dreamcatcher pug deep v blog seitan. Quinoa locavore skateboard bitters photo booth.

Slow-carb cray polaroid, hashtag selvage trust fund Vice salvia crucifix fixie mustache Schlitz pop-up American Apparel. Pork belly food truck hella messenger bag. Scenester ennui asymmetrical bitters disrupt.

Markdown

<blockquote class="pullquote">Dreamcatcher pug deep v blog seitan. Quinoa locavore skateboard bitters photo booth.</blockquote>  

Lists

Numbered List

1. Put on silly hat
2. Run around screaming wildly
3. ????
4. Profit

Markdown

1. Put on silly hat  
2. Run around screaming wildly  
3. ????  
4. Profit  

Un-ordered list

• Milk
• Apples
• Tortilla Chips

Markdown

* Milk
* Apples
* Tortilla Chips

Nested Lists

1. Fruit
   
   • Apple
   • Banana
   • Bread
2. Vegetables
   
   • Potato
     • Idaho
     • Red
     • Yukon Gold
   • Cheddar
   • Ketchup
3. Protein
   
   • Lengthy list items wrap nicely, so no matter what—even if they're super-rambling, talking about this or that, or that or this—even then, they still look clean.
   • Beans

Markdown

1. Fruit  
    * Apple
    * Banana
    * Bread
2. Vegetables  
    * Potato
        * Idaho
        * Red
        * Yukon Gold
    * Cheddar
    * Ketchup
3. Protein  
    * Lengthy list items wrap nicely, so no matter what—even if they're super-rambling, talking about this or that, or that or this—even then, they still look clean.
    * Beans

Media

Image with Caption

Image by Archbob, via morguefile.

<div class="caption">  
    ![image alt](/path/to/image.jpg)
    Image by <a href="http://www.morguefile.com/creative/AcrylicArtist">AcrylicArtist</a>, via <a href="http://www.morguefile.com/">morguefile</a>.
</div>  

Linked Image

Image by unageek, via morguefile.

[![image alt](/path/to/image.jpg)](http://example.com)

Video

All you need to do is copy in the embed code from YouTube and Scratch does the rest!

<iframe width="420" height="315" src="//www.youtube.com/embed/_OBlgSz8sSM" frameborder="0" allowfullscreen></iframe>  

Syntax Highlighting

For the programmers/bloggers out there, Scratch comes installed with the lightweight and wonderful Prism.js, which provides syntax highlighting on code blocks.

The markdown for a highlighted code block is:

```language-markup
<div class="your-code">
    <p>This is a great paragraph</p>
</div>
```

Some examples:

var coins = [200,100,50,20,10,5,2,1],  
    target = 200,
    combos = 0;

function add_coin(coin,subtotal) {  
    var sub_combos = 0;
    subtotal += coins[coin];
    if (subtotal > target) return 0;
    if (subtotal === target) return 1;
    for (var c = coin; c < coins.length; c++) {
        sub_combos += add_coin(c,subtotal);
    }
    return sub_combos;
}

for (var c = 0; c < coins.length; c++) {  
    combos += add_coin(c,0);
}

console.log(combos);  

<div class="content">  
  <p><em>HTML</em> syntax highlighting</p>
</div>  

a {  
    text-decoration: none;
    color: #f00;
    &:hover {
        text-decoration: underline;
    }
}

function update_title(new_title) {  
    var $title = $('title');
    $title.html(new_title);
}

If no <em>language</em> is specified, then no syntax <strong>highlighting</strong>.  

Tables

<table>  
  <thead>
    <tr>
      <th>Numbers</th>
      <th>Letters</th>
      <th>HTML</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>A</td>
      <td><strong>Looks</strong></td>
    </tr>
    <tr>
      <td>2</td>
      <td>B</td>
      <td><em>Pretty</em></td>
    </tr>
    <tr>
      <td>3</td>
      <td>C</td>
      <td><del>Nice</del> AWESOME</td>
    </tr>
  </tbody>
</table>  

Helper classes

.align-left {
    float: left;
}

.align-right {
    float: right;
}

.hidden {
    display: none !important;
    visibility: hidden !important;
}

Stop. Backspace that sentence and a half you've typed into the search bar and face the facts, man: Google has failed you. It's time to brandish your machete and start hacking.

Meet Counterpoint

Counterpoint is the project that's taken up the majority of my life for the past 3 months. It is a full-scale WordPress theme (which handles the blog's visual presentation), and is currently undergoing a review process before it is accepted into the WordPress Theme Directory, so anyone creating a new WordPress blog can use it as their theme, free of charge.

The development process was pretty intense, and I learned a ridiculous amount along the way. All in all, the code spans 39 files totaling 11 megabytes. And that doesn't even count all the debugged and rewritten code, which is where most of my time was spent.

It's not perfect. There are still plenty of things about it, visual or otherwise, which give me the heebie-jeebies. But it's really become something of a companion: as Counterpoint evolves, new coding challenges arise, pushing me to further my skills. As my skills develop, I test them out on Counterpoint, and the cycle continues.

During my journey I've been helped by an army of codices, blog posts, and even real-life humans. This post is an opportunity to give back, in whatever small way, so that when others confront similar issues, my solution is available as a reference.

The Goal

OKAY. At the top of my theme's blog index, I want to display the most recent sticky post (for the non-bloggers out there, you can mark a post "sticky" to make it appear at the top of your blog). The sticky spans the entire width of the content area. After that, I want all other posts to display normally, with a user-defined number of posts per page.

So, if the user sets their posts-per-page to 6, there will be a single sticky and six more posts on the front page---for a total of 7---and 6 normal posts on each subsequent page.

The reason for this is that I chose to display in 2 columns, and I don't want a big open space at the bottom-right side of the page. Because stickies stretch the entire width of both columns, taking up the space of two regular posts, it is necessary to ensure that the front page gets served an even number of posts following the sticky.

Otherwise this happens.

The Problem

Of course, I wouldn't be writing this post if it was trivial.

I'm not going to get too deep into the nitty-gritty on this post, but if you're interested in a more detailed explanation of the WordPress loop, there are plenty of good resources out there. For now, what you need to know is that "the loop" is what grabs all your blog posts via a query, which can be given different arguments to retrieve the exact posts you need.

The problem lies in the way WordPress handles sticky posts. If the sticky post is already supposed to appear on the front page, the usual behavior is to simply move it to the top. However, if the sticky post doesn't naturally appear on the front page, it will be added to the front page IN ADDITION TO appearing in its natural position. Let me rephrase that: sticky posts will appear either once OR twice depending on its position in the query.

It gets even more complicated. When a sticky is drawn from outside the front page, it doesn't count towards the posts-per-page limit. This means we'll end up displaying a different number of posts depending on where the sticky came from. Theoretically, even with posts-per-page set at 6, the front page could have any number of additional posts, depending on the number of stickies that were prepended to the query.

It's an interesting solution to avoiding duplicate material on the front page, but as you can see it does lead to some frustrating design issues:

• If I try setting posts-per-page to an odd number to avoid the space at the end of the page, every subsequent page has the gap.
• If I set posts-per-page to an even number, the design breaks when the sticky post is taken from the front page.

We can see that the normal loop is not going to help us here. No matter our settings, there is going to be a gap somewhere, and as a perfectionist, I cannot let that happen.

The Solution

The solution is two loops. The first loop displays the most recent sticky. The second displays the rest. However, if the sticky is from the front page, we get that silly duplication like this:

If it's such a problem, why don't I just skip that post in the second loop, thereby removing the duplicate? Unfortunately, to get a theme accepted into the WordPress Theme Archive, the natural behavior of duplicating a sticky in its normal, non-front-page position is REQUIRED. We'll have to be more clever than that.

Let's get started.

/* Loop #1 - for stickies
========================== */

// get an array of stickies
$stickies = get_option('sticky_posts');
// get the first one, or set it to false if none
$first_sticky = $stickies ? end($stickies) : false;
// get the posts_per_page variable (set by user)
$ppp = get_option('posts_per_page');


//  if a sticky exists and it's the front page...
if ( $first_sticky && is_front_page() && !is_paged() ) {

    // query the most recent sticky post
    $most_recent_sticky_post = new WP_Query( 'p=' . $first_sticky );

    // and display it
    while ($most_recent_sticky_post->have_posts()) : $most_recent_sticky_post->the_post();

        // code to display the post

    endwhile;

}
wp_reset_postdata();  

This is easy enough. Get the first sticky, query it, and display it. Then use wp_reset_postdata() to make sure subsequent queries are unaffected.

Before moving on to the main query, we first need to determine where the sticky came from. Sadly, this was one of those instances where google was not much help. My sketchy solution was to do an extra query and search for the sticky in the first 'n' posts, where 'n' is the user-defined posts-per-page. The result is stored in the variable $front_page_sticky. It's convoluted, but to my knowledge, it is the only way to do what I want.

$front_page_sticky = false;

// only do this if there's a sticky in the first place
if ( $first_sticky ) {

    // so here's the junk query
    $junk_query = new WP_Query(array(
        // ignore normal sticky behavior
        'ignore_sticky_posts' => 1
    ));

    // loop through the posts in $junk_query
    foreach($junk_query->posts as $post_num=>$junk_post) {

        // if it comes across the $first_sticky within the first page of posts...
        if ($post_num < $ppp && $junk_post->ID === $first_sticky) {
            // set this to true, then quit
            $front_page_sticky = true;
            break;

        // if there's no match, leave $front_page_sticky false...
        } elseif ($post_num >= $ppp) {
            break;
        }
    }
    wp_reset_postdata();
}

Cool. Now we have all the variables we need to set up our query arguments (we'll store them in a variable called $cp_args). Because every page of our results runs this same code, it's vital to make sure that it's served a specialized query for each page. Based on our desired behavior, there are two situations which require us to alter the default query:

1. if there is a front-page sticky
2. if we're not on the front page

Since these are not mutually exclusive, we'll check each with separate if-statements, adding the appropriate arguments to $cp_args.

// ignore sticky behavior no matter what
$cp_args = array(
    'ignore_sticky_posts' => 1
);

// if there is a front-page sticky, skip it in the query
if ( $front_page_sticky ) {  
    $cp_args['post__not_in'] = array($first_sticky);
}

// if we're not on the front page, set an offset so we don't get the same posts as the front page
if ( is_paged() ) {  
    $cp_args['offset'] = ($wp_query->query_vars['paged'] - 1) * $ppp;
}

All done! Now we can run the query.

// now for the main query
$main_query = new WP_Query($cp_args);

while ($main_query->have_posts()) : $main_query->the_post();

    // code to display the post

endwhile;  
wp_reset_postdata();  

One Last Thing

Any time we're not on the main blog index (for searches and archive pages), stickies don't apply, so I just want to do a basic query. For that, I'm going to wrap everything in:

if ( is_home() ) {

    // all of the previous code

} else {

    // run the default query if is_home() returns false
    // (i.e. search and archive pages)
    while (have_posts()) : the_post();

        // code to display the post

    endwhile;
}

Reflection

The programming community is extremely open with its intellectual property. Pretty much any and all new technologies and techniques are piously shared with the rest of the community, such that anyone skilled in Google-fu will discover it's almost hard NOT to find a wholesale solution to your exact problem, right there on the front page.

It makes sense. There's always bigger and more interesting problems to solve down the line, and it's lost productivity every time we reinvent the wheel---intentionally or otherwise. This culture of openness allows us to live and die on the bleeding edge. It's no wonder why so many programmers are passionate about open source projects---it's not just philosophy, it's the only game in town. As new programmers cut their teeth, they stand not on the shoulders of giants, but on those multitudes of code-pushing peons who surfaced for just a moment to ask a poorly-phrased question on a public forum.

Music. Math. Computers. As I move on to the next big thing, I am more and more sure that each step forward in programming is also a step towards self-actualization. In the set of variations so complete and sophisticated as one's life, the theme is often difficult to discern. But we can pick up on common aesthetic motifs, and in doing so, sometimes we get a glimpse of the whole composition. Eventually the threads will all come together, like the Finale of Beethoven's 3rd Symphony, a sonic boom of unity and perfect counterpoint.

One such figurehead of darkness is also one of the most fascinating figures in all of musicology. Carlo Gesualdo was an Italian nobleman infamous for murdering his first wife and her lover upon discovering them in an act of adultery. Depressed, guilty, and socially isolated, Gesualdo found expression through his compositions, which were arguably the most ecstatic and brazenly chromatic of the Renaissance, even the entire 17th century. Progressions of the sort found in his music were not seen again for 200 years.

Gesualdo's music is egoless, terrifying, and gorgeous. It's the mote of dust that you can't quite grasp. It's sleep paralysis. It's the realization that you're ultimately alone. It's absurdity. It's more than you or I can take.

Moro, lasso, al mio duolo,
E chi può darmi vita,
Ahi, che m'ancide e non vuol darmi aita!
O dolorosa sorte,
Chi dar vita mi può,
Ahi, mi dà morte!

I die, alas, in my suffering
And she who could give me life,
Alas, kills me and will not help me.
O sorrowful fate,
She who could give me life,
Alas, gives me death.

For two years since I turned my back on the masters degree program at the Cleveland Institute of Music, I felt as though I'd been stuck in a vicious pirouette, wobbling---NAY---nutating like a dreidel on a narrow outcrop above existential despair. So this past summer I wrenched myself free of Cleveland's desolation in the hope that some ill-advised change would effect a spiritual hard reset. On my second day in Austin, I went to a nearby coffeeshop and happened upon one of my favorite poets, Anis Mojgani, who was working on his laptop in the corner. His raspy "welcome to Austin, best of luck" and the impression of his oddly-shaped hand traced into my notebook were the good omen which validated my decision to move back south.

That said, for the first time since I created this blog in late November of 2012, this is not a post about music. Fuck that. I'm going to write about math.

Frankly, this should have been called Current Obsessions, as it's more true now than ever, but I couldn't relinquish the Shakespeare pun. When my roommate Lyle (AKA lobsterhands) announced that he was starting a degree in Computer Science, I watched over his shoulder as he showed me his code. This toggled in me a primordial boolean switch, causing a long-dormant passion for programming to emerge volcano-like from this teetering bulb of a man, and for the past month, I've spent like, 4-10 hours a day coding. Notably, this is an amount of time I almost never dedicated to cello practice.

Project Euler is a set of mathematical challenges intended to be solved with some sort of computer programming. To begin chipping away at the 400-something problems, I chose to use Ruby, a beautiful object-oriented language designed with readability and productivity in mind, and whose subtleties I have just barely begun to fathom. Many websites (e.g. Hulu) are built on implementations of Ruby.

Late last night I sat down to work out Problem 15:

Lattice Paths. Starting in the top left corner of a 2×2 grid, and only being able to move to the right and down, there are exactly 6 routes to the bottom right corner. How many such routes are there through a 20×20 grid?

You're not really supposed to share solutions, but a) this is more of a procedural explanation, b) my way isn't necessarily the quickest or the most intuitive, and besides, c) nobody reads my blog. So I'm going for it. I started by brute forcing my way to find the number of routes through the first few cells, then did some fiddling with formulas to determine the number of possible routes to each intersection in a given row. It looked like this, but messier:

The numbers correspond to the intersection to their bottom-right. Noting also that each intersection was the sum of the intersections above it and to the left---e.g. 35 = (15 + 20), 56 = (21 + 35), etc.---I made a recursive formula to find a given spot, but so many calculations meant it took AGES to come to an answer. Then, at approximately 4 a.m., after a stupid amount of intuition-driven scribbles, I stumbled upon an interesting relationship between any number on the top-right side of the grid and the number diagonally down and left. To find the answer for a 5x5 grid, all one needed to do was make x = 5 * 2, and work your way down and to the left, multiplying like so:

10  * (9/2) = 45  
45  * (8/3) = 120  
120 * (7/4) = 210  
210 * (6/5) = 252  

And that was that. There are 252 possible routes through a 5x5 grid. Thus, a 20x20 (or larger!) grid could be solved by hand:

40  * (39/2) = 780  
780 * (38/3) = 9880  
9880 * (37/4) = 91390  
.
.
.
etc.  

...or by a neat little Ruby program:

def lattice(gridsize)  
  total = gridsize * 2  # sets total at 2 * 20 = 40
  n = (total - 1)       # numerator = 40-1 = 39
  d = 2.to_f            # denominator = 2
  while n > d
    total *= (n / d)    # multiplies total by n / d
    n -= 1
    d += 1
  end
  total.to_i
end

gridsize = 20  
p lattice(gridsize)     # calls function, prints result  

What I later found out is that this problem is basically Pascal's Triangle and my solution is in essence the factorial expression for binomial coefficients:

Plugging in 5, we can see that the equations are equal:

That said, I'm not sure exactly why this works, but it's all pretty neat.

Now, basking in the post-coital contentment of a good math session, I realize that I am a lucky man. As Russell Edson might have said, the last couple years certainly pulled at the difficult head. The shame of quitting was (and is) real, but sometimes change beckons, and with it comes opportunity for salvation. Eventually I stopped spinning and found my balance, and as I backed away from the outcrop, I watched as the land, like Paschal's Triangle, opened up around me, and now suddenly, just as in older times, I am free to roam.