Unix aliases for long commands

I often tell my students that I am lazy as a programmer. I typically try to convince them that this is a good thing. The point I'm trying to make, of course, is that often the best line of code is the one you don't have to write.

Unix Aliases

The same principle applies when working in Unix. Many commands in Unix have numerous toggles, switches, and arguments. Some of these commands get quite long. Many of them are long commands I execute frequently. To minimize all that typing, you can create aliases. If you are at the command line (which you reach in Mac OS X by running the Terminal application), you can create an alias like so:

alias ll="ls -al"

Now, I can simply type "ll" at the command line instead of typing the longer "ll -al".

<h3>Saving Aliases</h3>

That is a nice start, but if you quit Terminal and return later, "ll" doesn't work any more. To make these aliases more permanent, you want to edit your .profile file (on other Unix flavors, you might edit .bashrc instead).

Listing: ~/.profile

# Aliases for commonly used commands
alias ll="ls -al"
alias iw="ssh markf@www.istarelworkshop.com"
alias bnr="ssh markf@www.bignerdranch.com"
alias bp="ssh broker@www.brokerpower.com"

There are two things to note here: first, spacing is important. Make sure there are no spaces on either side of the equal sign. Second, when you edit ~/.profile this way, the shortcuts will not be available to you until you open a new Terminal window.

Managing Provisioning for iOS Devices

The process for provisioning devices to deploy iOS apps has often caused confusion, or downright dismay. As versions of iOS have rolled on, the process has gotten easier, but there's a lot of old information and misinformation out on the web.

Clear Existing Profiles

Before doing anything else, make sure that all previous certificates and profiles are deleted (this prevents any muddying of the proverbial waters).

1. Open Keychain Access on your Mac and delete all developer-related certificates (look in the "My Certificates" category)
2. Open Xcode and go to Window > Organizer and delete any provisioning profiles (look in LIBRARY > Provisioning Profiles)
3. Log in to http://developer.apple.com and revoke your certificates (Go to the iOS Dev Center, then to the iOS Provisioning Portal, and click the "Revoke" button next to any certificate listed)

On that last step, the change happens quickly, but not instantaneously. You'll likely see "Revoke Pending", but if you are patient, a page refresh will show the certificate gone, and it will say something like "You currently do not have a valid certificate".

Xcode Does the Work

While it is possible to create and manage your certificates at http://developer.apple.com, it is easier to let Xcode do the work for you. Go back into Xcode and return to the Organizer. Make sure your devices are connected to the Mac.

For one of the devices, right-click on the Provisioning Profiles menu item under the device (e.g., Mark's iPad) and choose "Add Device to Provisioning Portal". You will get a sheet that says "No Developer Certificate Found". Click the "Submit Request" button.

That's it.

Additional Macs

As long as you develop only on that machine, and deploy apps only from that machine, your iPad or iPhone is perfectly happy.

There's a problem, though.

What if you plug your iPad into another Mac (say, your MacBook Pro)? The Provisioning Profile for the iPad says "Valid signing identity not found" along with a huge yellow banner that says "Xcode could not find a valid private-key/certificate pair for this profile in your keychain".

The problem is that Xcode doesn't trust the owner of the laptop. You need to export the private key for your identity on the iMac so that the laptop has that key as well. Then, your laptop will be trusted and you can deploy apps when the iPad is connected.

If you open Keychain Access (again) on the Mac where you did the "Xcode Does The Work" process, and look under "My Certificates", you will see an entry like "iPhone Developer: Your Name Here". Click the disclosure triangle for that entry. Now you'll see an entry named "Your Name Here" whose kind is "private key".

If you right-click on that private key entry, you have an option to "Export Your Name Here...". Select that and save the resulting file (make sure the .p12 format is selected from the dropdown). It will ask for a password (which you are creating to protect that key). Finally, it will ask for your admin password to allow keychain access.

Simply copy that file to the Mac where you want to be able to deploy apps and double-click on it to install it (you will be asked for the password you just created for the p12 file). If you relaunch Xcode, the "Valid signing identity not found" warning should disappear (you may have to go to the Provisioning Profiles area under LIBRARY in the organizer and click the "Refresh" button at the bottom of the window).

Now you are all set!

Install and Use Git Locally

Git is a powerful, flexible version control simple, one I find more intuitive than Subversion. Once again, I use MacPorts to install Git, and then I supply some global configuration settings.

markf$ sudo port install git-core
markf$ git config --global user.name "Mark Fenoglio"
markf$ git config --global user.email markf@istarelworkshop.com
markf$ git config --global color.diff auto
markf$ git config --global color.status auto
markf$ git config --global color.branch auto

The first two Git configuration commands set important defaults for identifying the author of changes to the repository. The last three commands define what colors to use when Git presents information in the console.

Create the Initial Git Repository

markf$ cd ~/Sites/iw
markf$ git init
Initialized empty Git repository in /Users/markf/Sites/iw/.git/

Ignoring Mac OS X Finder Detritus

One nuisance in Mac OS X when working with version control systems is (normally hidden) .DS_Store files created by the Finder. Git allows you to globally ignore files.

markf$ git config --global core.excludesfile ~/.gitignore
markf$ echo .DS_Store >> ~/.gitignore

Exclude Files from Version Control

In addition to being able to ignore certain files regardless of context, you can also ignore files for a specific Git repository. One common example of this is configuration files where the values of certain parameters will be different between development (local) and production (remote) environments.

markf$ cd ~/Sites/iw
markf$ vi .git/info/exclude
conf/ApplicationConstants.php
httpd.conf
install/conf/sh.conf
install/php/config.php

Initial Repository

Now that the appropriate files will not be part of the repository, I can create its initial version.

markf$ git add .
markf$ git commit -m "[install] initial repository"

The . in the first command is a wildcard that means add all non-ignored files to the current batch of changes. The -m switch on the commit command is the message to be included as the changes are committed to the repository.