If you’re like me and constantly displaying source files via cat, here’s a tip for making that output colorized.

First, make sure you have easy_install installed:

1
2
3

curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py
sudo rm distribute_setup.py

Next, install Pygments:

1

sudo easy_install Pygments

Finally, create an alias ccat (colorized cat) or something similar in your .profile or .bash.rc or .bash_profile:

1

alias ccat='pygmentize -O console256 -g'

Open a new terminal window or source the file containing your alias, and now you have colorized cat output!

I know a lot of people dislike Perl, but I programmed a lot of large applications in it for many years. I agree that it can be difficult for programmers new to Perl to pick up on some of its nuances, but I disagree that it’s a complete mess/line noise/write-only. Good clean code can be written in any language, just like horrible disgusting code can be written in any language.

A while back I saw a language speed shootout, whereby the same version of a script was written in many different languages and compared against each other to see how quickly they ran. Surprisingly, Perl has been so well optimized, that its performance was right on par with the C and C++ versions of the test. PHP, Ruby, Python, Java, etc. were all comparatively much slower. You could see the iterations of each getting much longer as the memory use increased. Yet Perl (and the C’s) stayed pretty consistent throughout.

Not being satisfied with someone else’s benchmarks, I ran the programs on a local machine. While the times were different, the results were nearly identical in terms of performance trends.

At my office, we frequently find ourselves switching between Git branches and often we forget to run composer install on the new branch to make sure our vender dependencies are at the proper versions for the branch we changed to.

For example, master is stable and has an older version of a dependency, but a feature branch I’m working on uses an updated version of that dependency.

Let’s say I’m currently working on a feature branch when a bug report comes in and I need to fix the problem ASAP. If I stash my current feature branch’s files, then create a new bug-fix branch off of master, my composer.lock file is different and my vendor/ directory still contains the newer version of the dependency. This occasionally causes problems.

A while back I found a helpful script to use as a post-checkout Git hook. Now whenever I switch branches, I get a notification telling me my dependencies are different than the branch I just switched from.

To use this script on a single project, put the following in your project’s .git/hooks/post-checkout file (create it if it does not already exist). Make sure to set the file permissions to executable.

I prefer to keep the script in my global git-core/templates/hooks/post-checkout file so it’s accessible for all of my projects. Tip: After installing the file, run git init in an existing project to update the hooks and bring the global file down locally to your project.

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

#!/bin/bash

PREV_COMMIT=$1
POST_COMMIT=$2

NOCOLOR='\x1B[0m'
REDCOLOR='\x1B[37;41m'

if [[ -f composer.lock ]]; then
    DIFF=`git diff --shortstat $PREV_COMMIT..$POST_COMMIT composer.lock`
    if [[ $DIFF != "" ]]; then
        echo -e "$REDCOLOR composer.lock has changed. You must run composer install$NOCOLOR"
    fi
fi

Please note: This script is modified to properly display color codes on a Mac/BSD system. If you’re on Linux and having display issues, change the instances of \x1B to \e and it will work for you.

From 1996 to mid 2004, I had my very own classic 80’s arcade in our house. The house had an enclosed screen room that was large enough to house 13 full-sized stand-up arcade machines. We also had two pinball machines, but those were in the kitchen (that’s a story for a different time).

They were fun to play, and provided endless entertainment when we had a party, or when the gang from work came by, or friends came by with their kids. With the lights out and all the machines being played, it truly felt like stepping back in time.

When it came time to sell the house, I had to get the machines out of there so that the house would show better. Granted, a home arcade would seduce lots of people, but it was in our best interest not to keep them there. Since 5 of them were in need of repair, and I really didn’t feel like moving them into a storage unit anyway, I decided to put them up for sale.

Fortunately there’s a market for those things, especially considering that mine were all in phenomenal shape. Even though some needed repairs, cosmetically they were mostly great. Needless to say, they were snatched up quickly. One local person bought 3 or 4 of them; someone drove down from Vegas for one, the rest sold to other collectors locally.

I miss having all of those machines, but I really miss those two pinball machines. Hindsight being what it is, I should have held on to those. There’s nothing like the feel of a good mid-80’s Bally/Williams pinball machine, and my two, High Speed and Pin*Bot, were my two favorites of the era. Maybe someday I’ll pick them up again.