Michael Wales

What Algorithm Runs an Elevator?

2026-06-26T00:00:00Z

I was standing in the lobby of my resort at Universal Orlando, waiting for an elevator, when the question caught me. Six cars, a small crowd, buttons lighting up faster than the doors could open. One car sailed past my floor without stopping. The other doubled back for someone who'd pressed down after I'd pressed up. And I found myself doing the thing I always do when something in the world won't leave me alone: wondering exactly how it decides. What's the logic in there? When two people on different floors both want a car, who wins? Is it just first-come-first-served, or is something cleverer going on?

For most of my life, that's where a question like this goes to die. You feel the itch on vacation, maybe you skim a Wikipedia article on the plane home, and the curiosity quietly evaporates because the gap between "I wonder how this works" and "I actually understand how this works" is wide enough that you never cross it. There's reading about a thing, and there's building the thing, and the second one is where understanding actually lives — but building used to be expensive enough that you saved it for work.

That gap has collapsed. So this time, instead of reading about elevators, I built a little world where I could run them myself.

Not really a game

What I ended up with is, nominally, a browser game: you write a JavaScript function that controls an elevator, run it against a simulated building full of impatient people, watch it play out, and get a score. But "game" undersells what I was actually after. I wanted a learning environment — something that would let me do three specific things:

Write my own algorithm and immediately see whether my intuition was any good. You're handed a working-but-naive elevator and a code editor; your job is to write the brain that decides where it goes. Run it and watch passengers wait — or not.
Compare it against the algorithms that already exist. The classic elevator-scheduling family — FCFS, SSTF, SCAN, LOOK — is built in. I can drop any of them into the editor, run them on the same building, and see their numbers side by side.
Actually see the difference. This was the part I cared most about. The simulation draws the shaft, the cars, and the people waiting on each floor — and the longer someone waits, the more they warm from yellow to red, so you literally watch a bad algorithm strand somebody in the corner while it fusses over closer, easier riders.

That last point is the whole pedagogical bet. It's one thing to read that "first-come-first-served has poor worst-case latency." It's another to watch a single red passenger sit on floor 14, fuming, while your too-greedy car ping-pongs around the lobby. The problem becomes felt before it becomes a sentence.

The answer I was actually looking for

Here's what I learned, which is the satisfying part. My resort question — is it just first-come-first-served, or something cleverer? — turns out to have a real, named answer with decades of computer science behind it.

First-come-first-served is the obvious idea, and it's terrible. It feels fair, but it makes the car thrash up and down the building chasing requests in the order they happened to arrive, blowing past people it's about to drive directly past. The thing real elevators actually do is called directional collective control, and the canonical version is the SCAN / LOOK family — affectionately, "the elevator algorithm." The car commits to a direction, shows you that direction, and serves every call going that way as it passes; if you want to go the other way, you wait for the return sweep. It only turns around when there's nothing left ahead of it. That single rule — commit to a direction and sweep — is most of why a real elevator feels orderly instead of frantic.

And then it gets deeper in exactly the way good problems do. Add a second car and the hard part stops being "where does this car go" and becomes assignment: which car should answer which call, so they don't both lunge for the same person and leave the rest of the building uncovered? Make the building tall and suddenly distance and energy matter as much as wait time, and you're trading objectives against each other — average wait versus worst-case wait versus floors traveled. There is no single "correct" elevator algorithm. There's a problem, a set of trade-offs, and a score to beat. That realization — that I'd wandered into a genuine optimization problem, not a trivia answer — was worth the whole trip.

AI as the workshop, not the answer

I want to be precise about the role AI played here, because I think it's the actually-interesting part and it's easy to get wrong.

I did not ask Claude "how do elevators work" and read the reply. That would have been the Wikipedia path with extra steps, and it would have skipped the only part that teaches you anything — the building. What I did instead was use Claude to construct the environment in which I could figure it out myself. I told it, in effect, to act as a pedagogy expert and help me build a tool whose entire job was to make me struggle productively: one new idea per level, each level designed so the strategy that won the last one visibly breaks; name the concept but never hand over the code; let me earn the worked solutions only after I'd cleared a level on my own. The tool is opinionated about not telling me the answer — and I'm the one who pointed it that way.

The result is that the loop from "idle curiosity in a hotel lobby" to "interactive thing I can poke at for hours" took a couple of days of nights-and-weekends tinkering, not a couple of months. That compression is the headline. The cost of chasing a question all the way down to a working artifact has dropped far enough that it's worth doing for its own sake — not for a deliverable, not for work, just because you got curious about an elevator. We talk about AI mostly in terms of shipping features faster. I think the quieter, bigger story is that it makes self-directed learning cheap: when the world makes you wonder about something, you can now build your way to actually understanding it.

On the fact that better elevator games exist

They do. There are elevator simulators and dispatch games out there that are richer, prettier, and more complete than mine, made by people who've spent far longer than four days on them. I want to be honest about that, because I think the honesty is the point rather than a disclaimer.

I didn't build this to compete with anything. I built it to answer my question, in a way that was engaging to me, scoped to exactly the things I was curious about and nothing I wasn't. That's a different goal than "make the best elevator game," and it's a goal that used to be uneconomical — you don't spin up a bespoke learning tool for an audience of one. Now you can. And because it's all client-side, runs offline, and lives in the open on GitHub, maybe it scratches the same itch for someone else who walked out of a hotel lobby with the same question. If it does, great. If not, I still got exactly what I came for.

The elevator, for the record, was almost certainly running LOOK.

Research at the Hourly Scale

2026-06-24T00:00:00Z

Talent is everywhere. Opportunity isn't. That sentence is most of the reason I joined CodePath as Senior Director of AI Programs, and it sits underneath everything we build. CodePath has spent almost a decade taking first-generation and low-income computing students - most from households earning under $60,000 a year - and getting them into real tech careers, at about a two-in-three rate. The talent was always there. What was missing was a door.

The program I'm spending most of my time on right now is Claude Corps, a paid, year-long fellowship we're running with Anthropic. We take early-career builders the hiring market would screen out, train them on the AI stack at an intensive in-person Base Camp, then embed them for a year inside nonprofits and mission-driven organizations that need that capability most and can least afford to buy it. CodePath owns the training and the bar for what a fellow can actually do; Anthropic brings the technology and the technical advisors. Every fellow leaves having actually done the job.

But this post isn't really about the program. It's about how we built it - and why that's only possible at a place like CodePath.

Before a single real fellow showed up, we ran the first month of the program as a simulation. I wrote up the full thing separately, but the short version: we built a synthetic cohort - a hundred host organizations, three hundred applicants, fifty mentors, none of them real people - ran our actual selection and matching rules on them, formed the pods, and played the month forward week by week. A wind tunnel for a program design. You'd never fly a plane you'd only ever drawn on a slide.

A few things mattered about how it was built. The engine that decides what happens is plain, deterministic rules - no AI improvising outcomes - so every result is an assumption we wrote down and can argue with, and anyone can rerun it and get the same answer. AI wrote only the layer on top: the first-person journal entries that let you feel a fellow's week instead of reading a spreadsheet, every word pinned to the underlying facts and checked. And a human reviewed every simulated week before the next one ran. The simulation isn't an oracle; it's a thinking aid. The people and outcomes in it are synthetic - we say that loudly and up front, because the moment a made-up number gets to pose as a forecast, you've lost the plot.

What it surfaced was less a verdict than a set of places to look. The pattern that came through most consistently was reassuring: wherever the right person caught a problem in time, the simulated fellow tended to recover - the support model seemed to do its job. The things that gave me pause were the ones support alone didn't appear to resolve. The clearest was capacity - our planned mentor-to-fellow ratio looked stretched well before any simulated crisis, which suggests it could be among the first things to buckle under real load. Another we started calling the quiet fellows: a couple of simulated fellows who kept reporting they were fine while falling behind, and weren't noticed until their work broke. If a pattern like that holds up with real people, it would point to detection, rather than help, as the thing worth investing in early.

None of this is settled - it's a synthetic cohort, not a forecast, and I don't want to dress up a hypothesis as a finding. But it's more than enough to act on cheaply: we're building a proactive, week-one check-in for the people who don't raise their hand, and we'll walk into the first real cohort already knowing where to watch. Far better to surface those questions in a model than to first run into them with a real mentor and two dozen real fellows in week three.

I think poking at our own design this early is the opposite of embarrassing. I'd be embarrassed to launch a program at real people without stress-testing it first. Every weak point the simulation flags now is a question we get to ask before a real fellow ever lives the answer. Credibility means being the first to look for the holes in your own work.

And this is where the hourly-scale thing comes in. At a lot of organizations, "run a simulation to pressure-test a strategic decision" is a quarter-long initiative with a steering committee and a slide deck to justify the time. At CodePath, this kind of work happens at the hourly scale. The resources, the technology, the time, and - critically - the leadership support are all there by default. You have an idea about how to make a program better, and the path from idea to evidence is measured in hours, not months. That isn't a perk; it's the point. We don't just teach the future of tech - we live it, building tools to think with, running the experiment, and letting the evidence change our minds.

I've started to suspect the method is bigger than the program. Most program designs live on a slide and get tested on real people. We made the argument executable: you run your design forward under realistic conditions and watch where it bends before anyone's year depends on it. Any organization planning something high-stakes could do the same.

We're Hiring

If any of this resonates, come build it with us. Working at CodePath, you get to directly impact the next generation of technologists and influence the lives of people the industry has historically overlooked - and you get the resources, technology, time, and leadership support to do rigorous, meaningful work while you're at it.

You can review and apply for open roles on our job board: job-boards.greenhouse.io/codepath.

Join me in the future of CS education.

Resurrecting a 2014 Codebase in 2026

2026-01-10T00:00:00Z

For many developers, software projects never truly die - they just become harder and harder to touch. The code still exists; the ideas still matter; the content or functionality still has value. What disappears first is the ability to reasonably maintain that code. Over time, dependencies rot, build tools get abandoned, and the cognitive cost of even small changes steadily rises until the only sensible option seems to be "don’t touch it." That was the state of this blog - not broken in concept, but brittle and immobilized under a decade of technical debt.

For years, this blog has had outdated information - locations, employers, etc. Simply because the technical overhead in getting things functional again didn't outweigh my other responsibilities nor the ability to just edit the source in Dev Tools and print to PDF whenever I needed a current resume.

When I set out to revive this blog, I wasn’t trying to resurrect a nostalgia project. What I was confronting was a classic technical debt problem: the system was stable enough to serve pages but too fragile to evolve. It was built on Wintersmith, a static site generator that hasn’t seen meaningful maintenance in years; it used Bower for front-end dependencies; it relied on Moment.js for dates; and it had no modern deployment pipeline. Any attempt to update a post or add a new feature would require untangling all of these brittle pieces first. In other words, it was trapped in its own legacy. I wanted to see whether an AI assistant could help liberate it.

The approach I took with Claude Code was not to ask for guides or to tell it what the new architecture should look like, but to provide the entire repository and a single directive: make this buildable and deployable again on contemporary tooling. What followed was a migration process that, by traditional measures, would have taken a developer at least a few days of uninterrupted work - possibly longer if they needed to reacquaint themselves with tools that haven’t been in common use for years.

The first substantive change the AI applied was migrating away from Wintersmith to Eleventy 3.x. Eleventy has emerged as a robust, versatile static site generator that embraces simplicity and extensibility, making it an excellent destination for this kind of project. Claude reconstructed the directory structure into Eleventy’s conventions, organized templates into _includes, applied readable date handling with Luxon instead of Moment, and rewrote syntax highlighting to use build-time Prism rather than client-side highlight.js. Every one of these decisions reflects a modernization that reduces runtime complexity and improves maintainability.

At every step, the AI had to reason about context that typically only a human engineer would understand. When Eleventy failed to build because templates couldn’t find base.njk, the system identified that Wintersmith’s layout placement did not align with Eleventy’s Nunjucks lookup paths and moved the files into a structure Eleventy expects. When initial GitHub Actions failed to trigger because the workflow was configured to watch the main branch while the repository’s default branch was master, Claude detected and corrected the discrepancy. Later, when the static site was being published to the wrong branch for GitHub Pages, the deploy workflow was updated to publish to master instead of main so that Pages would correctly serve the updated content. These are the kinds of integration and platform details that usually require reading documentation, trial and error, or painful debugging sessions; the AI internalized and applied them in real time.

Along the way, the repository was cleaned up: thousands of lines of obsolete configuration and unused assets were removed, replaced by a leaner, more modern codebase that reflected current best practices. A GitHub Actions workflow was introduced that builds and deploys the site automatically on push, eliminating the need for manual scripts.

The reason this matters is not because I was able to publish a blog post - it’s that a realistic, non-toy codebase was migrated, modernized, and restored to a state where it can be meaningfully improved again. Most abandoned projects don’t fail outright; they erode incrementally, and this erosion accumulates into a threshold beyond which no one wants to touch the code for fear of breaking something that nobody understands. Tools rot. Build processes become inscrutable. Developers forget the original mental model. What once might have taken a weekend of yak-shaving now can be addressed without painful context switching.

What this experience highlights is an evolution in developer productivity that goes beyond code generation. It’s not always about asking an AI assistant to write a new feature from scratch - it can be about using AI to restore the ability to reason about and work with existing systems. It can be about bringing a legacy codebase back into a form where the cost of change is low again. That unlocks a spectrum of opportunity: documentation sites that can finally be updated, internal tools that can be maintained without fear, prototypes that can be evolved into products, and so on. Instead of writing new code to replace old systems, we can now consider reviving them with far less investment than would have been plausible even a year ago.

This isn’t automation in the sense of replacing the developer. Throughout the process, I reviewed diffs, made architectural choices, accepted or rejected decisions based on intent and context. What the AI handled was the heavy lifting - the tedious, error-prone migrations and integration tweaks that typically occupy the margins of every significant change. With that burden reduced, developers are free to focus on what matters: reasoning about the user experience, the architecture, and the goals of the software itself.

Technical Appendix

This section exists for the people who want to understand not just that a legacy project was modernized, but how it was done and what kinds of transformations are now feasible with AI-assisted tooling.

Repository-Level Modernization

The original michaelwales.com repository was structured around Wintersmith, Bower, and hand-rolled shell scripts. Its directory layout looked roughly like this:

/contents
/templates
/plugins
/bower_components
/config.json
/build.sh

This layout assumed:

a global Wintersmith installation,
front-end assets fetched via Bower,
runtime JavaScript for things like syntax highlighting and date formatting,
and a human running build and deploy scripts locally.

Claude migrated this into a contemporary Eleventy-based static site with a structure more like:

/src
  /_includes
  /_data
  /posts
  /assets
.eleventy.js
package.json
.github/workflows/deploy.yml

This matters because it replaces implicit, tribal-knowledge-based build steps with explicit, reproducible infrastructure. Anyone who clones the repo can now run npm install and npm run build and get the same result, which is a non-negotiable requirement for sustainable software.

Template Migration: Wintersmith to Nunjucks (Eleventy)

Wintersmith templates were written in a dialect of Nunjucks but organized around layout inheritance rules that Eleventy does not share. For example, Wintersmith allowed templates to reference layouts by name regardless of location, while Eleventy requires layouts to live under _includes.

Claude didn’t just convert syntax — it re-modeled the template graph.

A Wintersmith page like this:

{% extends "layout.html" %}
{% block content %}
  <article>
    <h1>{{ title }}</h1>
    {{ contents | safe }}
  </article>
{% endblock %}

Was converted into an Eleventy-compatible version like:

---
layout: base.njk
---

<article>
  <h1>{{ title }}</h1>
  {{ content | safe }}
</article>

And the base layout was relocated into: src/_includes/base.njk

So Eleventy’s resolver could actually find it. This is a perfect example of where most migrations stall: the syntax might be "compatible" but the tooling assumptions are not. AI was able to discover, test, and correct those mismatches iteratively.

Syntax Highlighting: Runtime to Build Time

Originally, syntax highlighting was done in the browser using highlight.js. Claude replaced this with Eleventy’s Prism integration, so code blocks are rendered as HTML during the build.

Before:

Browser downloads highlight.js
DOM is scanned
Code blocks are post-processed

After:

Markdown → HTML with Prism classes at build time
Zero runtime cost

This again reflects a broader pattern: AI naturally gravitates toward architectures that are simpler to reason about and less fragile in production.

GitHub Actions: From Shell Scripts to CI

The old deployment flow relied on shell scripts that pushed a built directory to GitHub Pages manually. Claude replaced this with a GitHub Actions workflow:

name: Build and Deploy Eleventy Site

on:
  push:
    branches:
      - master

jobs:
  build-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm run build
      - uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: $
          publish_dir: ./_site
          publish_branch: master

Two interesting things happened here:

The AI initially assumed the default branch was main, then corrected itself when the workflow failed.
It discovered that GitHub Pages was serving from master, not gh-pages, and updated the deploy target accordingly.

That kind of "platform awareness" is exactly what makes legacy projects so expensive to maintain — and what AI is now able to absorb.

Codebase Shrinkage as a Signal

One of the strongest signals of success was the net change in the repository:

~35,000 lines removed
~2,000 lines added

Most of what disappeared was:

vendored libraries,
legacy build glue,
unused scripts,
obsolete configs.

What replaced it was:

a modern dependency graph,
a single, readable build pipeline,
and a small, understandable project footprint.

That ratio is what real modernization looks like.

Why This Works Now

None of this required "understanding" in the human sense. What the AI brought was something else: the ability to navigate, simulate, and adapt complex systems quickly enough that exploration is cheap.

This is what makes old codebases newly valuable. They don’t need to be rewritten; they need to be translated forward.

That’s the real unlock.

Some Fun Things to Note

I have a lot of experience with AI in the form of OpenAI's/Anthropic's chatbots, or Cursor's/Windsurf's/VSCode's in-IDE experiences, but my history with agentic AI experiences is pretty minimal right now - probably limited to various iterations of BMAD in all of the tools previously mentioned.

Claude Code did phenomenally well here and I'm happy with the results, but I was surprised as how quickly I burned through all of my tokens for a 6-hour block of time (Claude Pro). I did use Opus and planning mode for the first prompt or two, until I felt like I understood the plan it was coming up with and trusted it to "just go do things" - more experimentation is in order on my part to figure out the best times to opt-in to the more resource intensive compute.

Make .gitconfig Work for You

2014-03-19T00:00:00Z

Git has undoubtedly become one of the most important tools within any Web Developer's bag of tricks, arguably due to amazing success of GitHub. Unfortunately, Git can be quite overwhelming - particularly for those developers new to distributed version control systems.

This complexity leads some developers to seek out graphical Git clients to assist them in managing their workflow correctly. Although there are a great number of excellent GUI-based clients, I've always enjoyed using the command line instead. It's through the command line tools that Git's true power, and flexibility, shine through and today I'd like to discuss one of Git's strongest "utilities": the .gitconfig file.

A .gitconfig file can reside in up to three locations within your filesystem, the location determining the scope in which the file's contents are considered:

Global (~/.gitconfig): The most common use, establishes global configuration options for a particular user.
System (/etc/.gitconfig): Rarely used, establishes configuration options for the entirety of the local system (all users on this computer).
Local (~/Projects/this-project/.gitconfig): A the repository level, establishes configuration options that only affect this repository. If this file were committed, the settings contained within would impact all users that clone this repository.

Since we're primarily interested in making configuration changes that will make our own lives easier, without affecting other users, we'll focus on the global .gitconfig file. You should first check to see if you have a .gitconfig file within your home directory and create one if you do not (Unix commands provided, Windows users should make the appropriate modifications as necessary):

$ cat ~/.gitconfig
cat: /Users/mike/.gitconfig: No such file or directory

$ touch ~/.gitconfig

Common Endpoint Shortcuts

Although GitHub is by far the most popular place to host a repository there are a number of other options. BitBucket is a popular provider for many businesses, primarily because their pricing model focuses on number of users rather than if a repository is public or private (in other words, unlimited free private repositories). Gist, a GitHub service, is great for hosting quick snippets of code that don't really need to be associated with a huge project - each snippet is its own fully functional repository.

Throughout the course of a day, I could be interacting with repositories from a number of providers. Having to type out the full URL, and undoubtedly fat-fingering those URLs a few times, would not only be a huge annoyance but could actually kill off a few precious minutes each and every day. Fortunately, we can configure shortcuts within our .gitconfig file using the url.insteadOf setting. In the following examples, I have configure the gh:, bb: and gist: shortcuts to point to their full URL:

[url "https://github.com/"]
    insteadOf = gh:

[url "https://gist.github.com/"]
    insteadOf = gist:

[url "https://bitbucket.org/"]
    insteadOf = bb:

With this configuration in place, here's how I would then clone a few example repositories (notice how I'm only having to concern myself with the namespace and project name of the repository I am cloning):

$ git clone gh:walesmd/walesmd.github.io

$ git clone gist:walesmd/7315613

$ git clone bb:walesmd/codeigniter-erkana-auth

Colored Output

If you've put a lot of hard work into building out the perfect shell prompt, like I have (a topic for a future post) you may find Git's monochromatic responses to be a bit dull. Not only does coloring provide an aesthetic appeal it can prove to be quite functional as well. We instinctively associate the color green with success or that everything is okay; inversely, red indicates a warning or a problem. I've configured a number of various colors within my own .gitconfig to help me easily identify changes to a repository, identify branches and more.

[color]
    ui = true

[color "branch"]
    current = yellow reverse
    local = yellow
    remote = green

[color "diff"]
    meta = yellow bold
    frag = magenta bold
    old = red bold
    new = green bold

[color "status"]
    added = yellow
    changed = green
    untracked = red

Aliases

My first introduction to distributed version control was with Mercurial, whose commands come with a number of shortcuts (ci for commit, br to list branches, etc). A number of these shortcuts were muscle memory by the time I made the transition to Git, so I needed a way to port these various shortcuts over. Once again, Git promises to deliver in the form of aliases.

You may have seen various aliases provided in other articles, typically in the form of a single command within your shell. git config --global alias.ci commit, for example creates a new alias (ci) associated with commit. But, did you know these commands aren't doing anything that special or magical to your Git environment? In fact, git config is simply a command to read and write to various config files, .gitconfig included (and with the --global switch, we make sure we're editing ~/.gitconfig).

Below I've provided a number of my favorite aliases, with inline comments to futher explain those that may be a bit confusing. As you review this list, take note of any alias definitions that are preceded by a !. This tells git to run that entire command is if it had been entered directly within a shell and is required if you are piping results or running multiple commands:

[alias]
    # Add and remove all changes, note how this alias is calling another alias
    addremove = !git r && git add . --all

    # Show all of my configured aliases
    aliases = !git config --list | grep 'alias\\.' | sed 's/alias\\.\\([^=]*\\)=\\(.*\\)/\\1\\ \t => \\2/' | sort

    # For when you made that commit a bit too early, amend
    amend = !git log -n 1 --pretty=tformat:%s%n%n%b | git commit -F - --amend

    # Show all branches
    br = branch -av

    # Show the current branch name (usefull for shell prompts)
    brname = !git branch | grep "^*" | awk '{ print $2 }'

    # Delete a branch
    brdel = branch -D

    # Which files are receiving the most "love"
    churn = !git log --all -M -C --name-only --format='format:' "$@" | sort | grep -v '^$' | uniq -c | sort | awk 'BEGIN {print "count,file"} {print $1 "," $2}'

    # View the log and diff for a commit (previous if no SHA1 provided)
    details = log -n1 -p --format=fuller

    # Save a repo as a tarball
    export = archive -o latest.tar.gz -9 --prefix=latest/

    # Unstage changes from the index
    unstage = reset HEAD --

    # View a pretty git log with branch tree
    g = !git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

    # Return a list of commit SHA1s
    l = "!f() { git log $* | grep '^commit ' | cut -f 2 -d ' '; }; f"

    # Remove deleted files
    r = !git ls-files -z --deleted | xargs -0 git rm

    # Return the repository's root directory (usefull for shell prompts)
    root = rev-parse --show-toplevel

    # Update all submodules
    subup = submodule update --init

    # List all tags
    tags = tag -l

    # Start a new local repository and perform initial commit
    this = !git init && git add . && git commmit -m \"Initial commit.\"

    # Thin out older metadata within the repository, reduceses filesystem footprint
    trim = !git reflog expire --expire=now --all && git gc --prune=now

My Complete `.gitconfig`

I haven't covered every single entry within my .gitconfig file, just what I believe have been some of the most helpful changes I've made. If you're interested in reviewing my entire file, I present to you:

[alias]
    addremove = !git r && git add . --all
    aliases = !git config --list | grep 'alias\\.' | sed 's/alias\\.\\([^=]*\\)=\\(.*\\)/\\1\\ \t => \\2/' | sort
    all = add . --all
    amend = !git log -n 1 --pretty=tformat:%s%n%n%b | git commit -F - --amend
    br = branch -av
    brname = !git branch | grep "^*" | awk '{ print $2 }'
    brdel = branch -D
    ci = commit
    changes = "!f() { git log --pretty=format:'* %s' $1..$2; }; f"
    churn = !git log --all -M -C --name-only --format='format:' "$@" | sort | grep -v '^$' | uniq -c | sort | awk 'BEGIN {print "count,file"} {print $1 "," $2}'
    co = checkout
    details = log -n1 -p --format=fuller
    export = archive -o latest.tar.gz -9 --prefix=latest/
    unstage = reset HEAD --
    g = !git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
    in = pull --dry-run
    l = "!f() { git log $* | grep '^commit ' | cut -f 2 -d ' '; }; f"
    out = log --branches --not --remotes
    r = !git ls-files -z --deleted | xargs -0 git rm
    root = rev-parse --show-toplevel
    st = status
    subup = submodule update --init
    tags = tag -l
    this = !git init && git add . && git commit -m \"Initial commit.\"
    trim = !git reflog expire --expire=now --all && git gc --prune=now

[credential]
    helper = osxkeychain

[color]
    ui = true

[color "branch"]
    current = yellow reverse
    local = yellow
    remote = green

[color "diff"]
    meta = yellow bold
    frag = magenta bold
    old = red bold
    new = green bold

[color "status"]
    added = yellow
    changed = green
    untracked = red

[core]
    autocrlf = input
    compression = 9
    excludesfile = ~/.gitignore_global
    filemode = false

[diff]
    mnemonicprefix = true

[merge]
    log = true
    ff = false

[push]
    default = simple

[url "https://bitbucket.org/"]
    insteadOf = bb:

[url "https://github.com/"]
    insteadOf = gh:

[url "https://gist.github.com/"]
    insteadOf = gist:

[user]
    name = Michael Wales
    email = webmaster@michaelwales.com

Learn Web Development, First

2014-02-20T00:00:00Z

I recently read Rob Conery's PHP or ASP.NET: Did I Do The Right Thing? Although it does a great job uncovering how a developer can literally lose half a decade of their life by focusing their efforts towards the wrong technologies, I can't help but feel as if Rob is still asking himself the wrong questions, focusing on symptoms rather than the problem itself.

Toward the end of the article Rob imagines five ways his professional life would be better today, had he not focused on ASP.NET (presumably, if he had focused on PHP):

Know Linux a whole lot better

Be very familiar with MySQL and other open databases

Be less scared of JavaScript than I was 4 years ago

Be less reliant on an IDE

Love HTML and CSS

Let that sink in for a moment... here we have a Web Developer that is/was scared of JavaScript, doesn't enjoy HTML or CSS, is unfamiliar with open source databases and is arguably uncomfortable with Linux. These are the very foundations upon which the web was built!

By no means are my intentions to pick on Rob - I don't know him personally, nor am I familiar with his work; rather, I look to him as an example (and I believe this was his intent with his article).

The framework doesn't matter. Whether it's PHP, Rails, ASP.NET or NodeJS - these are just proxies by which you write software for the web and the languages of the web are HTML, CSS and JavaScript. If you're not comfortable, I dare say in love with these three languages, you're not a Web Developer.

By all means, you may be the best PHP developer the world has ever known; you'll find a job in which you are a mentor to those that work with you, you'll live comfortably and you'll love the work that you're doing. But, if there's one fact within the world of web development it is this: frameworks/languages, which are nothing more than varying syntaxes to achieve the same result, come and go.

In a few years, your product will be forced to evolve as the industry continues to evolve. As history has shown us, this more than likely will lead to a new languge or framework, a new way of thinking; the only constant within this vicious cycle are HTML, CSS and JavaScript. As you're packing up your belongings into a box you'll look back at the remainder of your team, the Web Developers.

If you're just starting out, or perhaps you describe yourself as one of these silo developers - only focused on a single technology - I encourage you to focus on the basics. Learn web development, first; then, feel free to explore various supporting languages.

Consider this: would you trust a surgeon or specialist, knowing they completely ignored the foundation of general medicine?

Getting Started with GulpJS

2014-02-12T00:00:00Z

Like many others, I incorporated a task runner (namely GruntJS) into my workflow some time ago. If you tend to use "preprocessed languages" like CoffeeSript, LESS or Sass it's virtually a requirement in maintaining your sanity. Although I prefer sticking to vanilla JavaScript and CSS, introducing this step into my development cycle has certainly paid off in man-hours saved alone. Tasks such as linting or minification during the build process, previously requiring text editor plugins or an array of terminal commands to remember, are now diminished to mere after-thoughts. Best of all, these tasks can now be versioned within your project's repository ensuring a consistent result despite varying environments in which a task may be run.

For some time now, GruntJS has been the de-facto task runner. It's plugin respository boasts more than 2,200 available plugins, 27 of which are officially maintained by the GruntJS team and cover the most common of tasks such as running JSHint, concatenating files, compiling CoffeeScript and much more. Nevertheless, the developers at Fractal felt the need for an additional option, pairing their own unique ideas with NodeJS' Streams API.

Their efforts have resulted in Gulp, an amazingly fast task runner, and it's gained quite a following amongst developers with nearly 300 plugins of its own. Not only do Gulp tasks execute much quicker than comparative Grunt tasks, but I've found the process of actually writing tasks much simpler. I spend less time managing a project's supporting toolset, allowing me to focus on the most important goal: shipping.

Unlike Grunt, in which tasks are defined via a rather verbose configuration API, in Gulp you're just writing plain ol' JavaScript - you program your tasks, rather than configure them. Consider the following gruntfile.js that runs JSHint, minifies and concatenates every JavaScript file within a directory:

module.exports = function(grunt) {
    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),

        jshint: {
            files: ['src/js/*.js'],
            options: {
                jshintrc: true
            }
        },

        concat: {
            build: {
                src: ['src/js/*.js'],
                dest: 'build/app.js'
            }
        },

        uglify: {
            build: {
                files: {
                    'build/app.min.js': ['<%= concat.build.dest %>']
                }
            }
        }
    });

    grunt.loadNpmTasks('grunt-contrib-jshint');
    grunt.loadNpmTasks('grunt-contrb-concat');
    grunt.loadNpmTasks('grunt-contrib-uglify');

    grunt.registerTask('default', ['jshint', 'concat', 'uglify']);
};

To do the same, using Gulp:

var gulp = require('gulp'),
    jshint = require('gulp-jshint'),
    concat = require('gulp-concat'),
    uglify = require('gulp-uglify');

gulp.task('jshint', function() {
    gulp.src('src/js/*.js')
        .pipe(jshint())
        .pipe(jshint.reporter('default'));
});

gulp.task('build', function() {
    return gulp.src('src/js/*.js')
        .pipe(concat('build/app.js'))
        .pipe(uglify())
        .pipe(gulp.dest('build/app.min.js'));
});

gulp.task('default', function() {
    gulp.run('jshint', 'build');
});

I find this much easier to understand and, more importantly, modify. Rather than worry about performing a task within the strict confines of an API, which often leads to temporary directories and files as tasks become dependent upon the output of other tasks, we're just piping streams through modification functions. There's no need to distinguish between a plugin's native tasks and the project's tasks - a task is a task is a task.

If you'd like to give Gulp a spin, perhaps rewrite one of your own Gruntfiles (don't worry, the two can live side-by-side without conflict), the installation is just as simple as most other node packages.

First, install gulp globally:

npm install -g gulp

Then, install gulp and gulp-util in your project's devDependenies:

npm install --save-dev gulp gulp-util