the tourist

Week One of My Pairing Tour

Last week (5/13-5/16) was the first week of my pairing tour, a two-week period where I pair with a different 8th Light craftsman each day. Last week I worked with Dave, Patrick, Dariusz, and Craig. I worked on Rails apps, wrote some Ruby code, and paired on a Node app. I learned a lot, both about code and about how to effectively pair.

There are several things about pairing that I noticed as I moved from project to project, craftsman to craftsman, each day trying to gain enough context quickly enough to contribute.

• Verbally communicate at all times.

The best work happens when you and the developer you’re pairing with are constantly talking. You should explain your reasoning when necessary, describe what you’re doing, and ask for feedback. There should be a constant flow of communication.

• Alternate driving frequently.

It can be tiresome to drive for long periods of time and similarly, you can find yourself feeling fatigued and almost absent when the other person is driving for a long time. It’s really great when you can get in the rhythm of alternating frequently. One strategy for achieving this is ping-pong pairing.

• Be engaged when you’re not driving.

Sometimes it’s strange to be the “other” person in the pair, the navigator, the one without the keyboard and mouse. It’s important to be engaged in the process by asking questions, providing suggestions, and most importantly, letting the driver know when they’re moving too fast or going in a confusion direction.

Pairing has many advantages. As you’re pairing, you’re sharing knowledge. You’re learning about the codebase, the design and architecture, the domain, the technologies being utilized (language, framework, etc.). Sharing knowledge helps you avoid a very common situation where all domain knowledge belongs to one developer. If that person leaves the company or takes a week off, everything stalls.

Pairing invites debate and forces developers to explain their reasoning. It provides accountability and leads to cleaner, smarter, more well-written code. That is the most fascinating part about pairing. It’s true that over the course of the day, you might get slightly less done. But in the long run - because you’ve written better, more maintainable code - you ultimately save time.

Pairing can be a great way to learn. Someone is always teaching (and therefore learning, too) and someone is always learning. But it’s a skill, not just something you do. It takes practice and the first week of my pairing tour definitely reinforced that.

Updating Your Bash

OSX’s bash is terribly out of date, as was pointed out to me today by 8th Light Craftsman Eric Meyer.

My machine was using bash 3.2.48 and the most recent version of bash is 4.2. In this post I’ll walk you through the steps needed to update your bash.

But first, an unexpected and exciting (and brief) look into tar files! TAR stands for Tape Archive. Why? Well, originally it was designed for tape backups. What the heck is a tape? There’s a device called a tape drive that reads and writes data on a magnetic tape. Check it out!

Wow! That thing looks like it’s a hundred years old! In contrast to a disk drive, which can move to any position on the disk in milliseconds to retrieve data, a tape drive must physically wind tape between reels to read data. But what you lose in speed you make up in cost. Tape drives are much less expensive.

So we go grab this tar file of the newest version of bash. (Note: a tar does not compress the files).

First, click here to grab the tar of bash 4.2.

Enter the Downloads folder.

cd ~/Downloads

Let’s learn about some tar commands now that we have a tar file to deal with.

• z uncompress before extracting
• x is to extract files ending in .tar.gz or .tgz
• v is to be verbose as it’s extracting

• f is filename to follow

  tar zxvf bash-4.2.tar.gz
  

Wait! What is this .tar.gz extension? Remember when I told you tar files aren’t compressed? .tar.gz files are compressed tar files, which is why we had to supply the z flag to uncompress before extracting it.

Look at Wikipedia’s pretty picture of it all!

Alright, now hop into your brand new, freshly created bash-4.2 folder.

cd bash-4.2

Now we’ll just run three commands in a row all on one line. These three steps are very standard for obtaining software directly from the source code.

We’ll execute the configure script, the make command uses the makefile to determine what needs to be recompiled (and recompiles them). It does not recompile the entire program, only what’s needed.

make install performs the install, also specified in the makefile (which is essentially a file of instructions). It’s common for this command to install executables after the compilation process is complete.

The binary is installed at /usr/local/bin/bash.

./configure && make && sudo make install

Change your login shell to the bash shell you just downloaded.

chsh -s /usr/local/bin/bash your_user_name

chsh only allows you to switch to the shells listed in /etc/shells, so we need to register the new binary as a valid shell. The bash manual tells us that if the -c option is present commands are read from string.

sudo bash -c "echo /usr/local/bin/bash >> /private/etc/shells"

Enter the bin folder.

cd /bin

Re-name bash folder to bash-old, thereby creating a “backup” copy.

sudo mv bash bash-old

Create a symlink to point /bin/bash to /usr/local/bin/bash.

sudo ln -s /usr/local/bin/bash bash

Now if you run this command you can check the version of bash you’re using.

bash --version

And finally, read about the new stuff in bash 4.X.

Some Helpful Stuff

The Ultimate Tar Command Tutorial with 10 Practical Examples

BashGuide

Learning the shell

Running a PHP App Locally Using Apache

Today Paul asked Nhu (a fellow apprentice) and I to get a PHP app running locally so he could begin the process of determining the best way to re-write it as a Rails app.

We weren’t very familiar with PHP or Apache, the web server we decided to use, so it took a while to figure everything out. We have the app running locally now and I wanted to explain how we got there.

Apache and PHP come with OSX, but they aren’t enabled by default. The Apache binary running under Unix is called HTTPd (for HTTP daemon). The core of Apache is fairly basic and the server integrates easily with PHP and many databases.

cd /etc/apache2

This is where your machine’s Apache server is located. You’ll see a number of files and folders here, including one called httpd.conf. Apache is going to look at these *.conf files (configuration files) to determine a number of things, such as what port to listen on.

This file needs to be edited, but it’s read-only so you’ll have to change permissions on the file.

sudo chmod 755 httpd.conf

755 is the same as u=rwx,go=rx, meaning that you’re giving the user read, write, and execute privileges, and the group and other privileges to read and execute only (but not to write). Read permission is assigned a value of 4, write is assigned 2, and execute 1. So giving read, write, and execute privileges is 4+2+1 (7), hence the reason for 755.

Next, we needed to uncomment a line in this config file that contains this command:

# LoadModule php5_module libexec/apache2/libphp5.so

Uncommenting this line is effectively enabling PHP.

At this stage we are ready to start the Apache server. We can start and stop (and restart) with these commands:

sudo apachectl start
sudo apachectl stop
sudo apachectl restart

But what files are we serving? If we visit localhost what will we see? Well, if we go back to the config file we edited earlier and take a look around line 165 we’ll see a commented out chunk of text explaining something called DocumentRoot.

# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.

DocumentRoot "/Library/WebServer/Documents"

So by default it will take files from this location to serve. There is an index file there that’s served when we hit the root route. It gives us the reassuring message “It works!”.

We wanted to serve our PHP app so we copied it to this directory and we were all set.

Some Helpful Stuff

An Introduction to Apache

Introduction to the Apache Web Server

Running PHP on the Mac OS X Leopard Apache Web Server

PHP: Built-in web server

Apache HTTP Server