Let’s have a little fun on a Friday. What’s the command prompt on your local machine?

via Ryan

I use Zsh, so I also have a right prompt. Most of this is pretty obvious, but I’ll explain some of the cooler things that might not be.

  • dashboard is the current branch I’m on in a git repository
  • fda1011 are the first 7 characters of the hash of the current commit
  • The X means there are uncommitted changes
  • The arrow is green when the return code of the last command was 0 and red otherwise
  • cd automatically calls ls as well

It’s all available on Github.

Git essentials for SVN users

Coming from Subversion, the extra steps involved in working with a Git repository can be confusing. Here are some basic concepts and commands to get started with Git.

I find that actually doing something is the best way for me to understand. If you’re the same way, the Github tutorial by Code School is great.


There are a couple conceptual differences between Git and Subversion that it helps to understand before getting started.

Centralized vs Distributed

Subversion is centralized version control — every commit lives on a central server. Git is distributed version control — everybody has a copy of the repository. When you commit to subversion, the push to the central server is implicit. The commit and push are discrete actions in Git. This means you can do work and commit changes without necessarily being connected to the Git server. Another advantage is the ability to make commits locally without necessarily publishing your work.

File vs Change-based version control

Subversion is file-based — when you make changes and run svn commit, it commits all the changed files by default. Git is changed-based — when you make changes, you have to run git add to “stage” changes. You can get similar behavior to Subversion with git commit -a. The “a” flag tells Git to add all changes in tracked files.


  • init – Create a new repository.
  • clone – Set up a repository that already exists on a remote server.
  • add – Stage changes to be committed.
  • commit – Add changes to the local repository.
  • push – Push unsynced commits to a remote repository.
  • pull – Pull unsycned commits from a remote repository.

Basic Workflow

  1. Get the latest version of the code. If you already have the repository, you can use git pull to get the latest changes. Otherwise, git clone will download the code from a remote repository and set it up locally. If this is a new repository, you can set it up with git init.

  2. Make changes.

  3. Share your changes. git add <file>; git commit; git push or git commit -a; git push.

Listless Nav Menu in WordPress

Chris Coyier recently posted an article about using lists in navgiation on CSS Tricks. I tend to agree that they’re unnecessary. The first time I built a menu with a nav wrapping a ul wrapping a bunch of li‘s wrapping a bunch of a‘s it felt gross, but I did it because I thought that was easier for screen readers to understand.

I just redesigned my site and decided that I wanted a simpler structure for my menu this time. Since WordPress builds menus in lists, I created a custom walker class for wp_nav_menu that formats the menu the way I want.


That looks like a lot. It’s mostly just a copy of the Walker_Nav_Menu class with a few things changed:

  • Change the default container to ”
  • Change the default wrapping element to nav instead of ul
  • Disable a fallback1
  • Change the sub-menu element to div instead of ul
  • Remove the li wrapping each link
  • Put the id and class‘s that would normally go on the li on the a instead.

Of course, you have to tell your nav menu to use this walker. Since this disables the fallback if you don’t have a menu set, you’ll have to specify a menu.

  1. Unfortunately the fallbacks generally aren’t compatible with custom walkers — at least not the same custom walker that can be used for wp_nav_menu 

Pow with Laravel

In the past1, I’ve been a big fan of running a virtualized web server locally instead of intalling PHP and Apache (or Nginx) directly on my development machine. I think I just changed my mind.

A little over a month ago, I read Elliot Jay Stocks’ article abou the stuff he missed on vacation. One of those things was the release of Anvil. Anvil is really just a nice looking front-end for Pow. Pow is a local rack web server built on node.js. It adds some cool stuff to /etc/resolvr to handle DNS for development domains and then you just symlink a directory into ~/.pow to get a server at a domain like .dev.

For some reason I’ve never really been a fan of MAMP. I think the “zero-config” thing stuck with me when I saw Pow though. So I started looking around2 to see if I could use Pow with PHP apps.

It turns out to be possible. There’s a gem called rack-legacy which is exactly for this purpose. Unfortunately rack-legacy uses the CGI version of PHP which doesn’t come in Mountain Lion. So you have to install PHP from source, which requires you to install mcrypt from source as well.

  1. Install mcrypt from source.
  2. Download the PHP source over at the PHP Downloads page.
  3. cd into the PHP source directory and configure it ./configure --with-cgi --enable-mbstring --with-curl --with-xmlrpc --with-mcrypt=/usr
  4. make and make install PHP.

So, now that we have PHP set up, install Pow, Rack, and all the other dependancies.

brew install node sqlite
gem install rack rack-legacy rack-rewrite
curl get.pow.cx | sh

I think the only dependancy for pow is node, which I used homebrew to install. I also installed sqlite because it’s easier to use locoally than MySQL. And Laravel makes it simple to switch over to a SQLite database.

It’s finally time to set up our Laravel app. Rack apps need a config.ru file in the root which is just a Ruby script that configures the server for this particular app. Put the following config.ru in Laravel’s public folder and point Pow at the same folder.

require 'rack'
require 'rack-legacy'
require 'rack-rewrite'

use Rack::Rewrite do
send_file %r{([^?]+)}, Dir.getwd + '$1', :if => Proc.new { |env|
path = File.expand_path(Dir.getwd + env['PATH_INFO'])
rewrite %r{(.*)?}, 'index.php$1'

use Rack::Legacy::Php, Dir.getwd
run Rack::File.new Dir.getwd

That’s it.


There were kind of two main resources that I used to fully understand what was going on here and how to set this up. If you’re going to be a PHP developer and use Ruby tools, get used to seeing PHP as “Legacy Development” I guess.

  1. Legacy Development with Pow
  2. Configuration file to use PHP with rack

  1. I’ve written a few articles about setting up a VM in VirtualBox for PHP development locally. Including the original, part 2, the one about nginx, and the video

  2. I even considered writing my own “zero-configuration” web server that would work with PHP for a minute.