Honestly, I can’t remember if Subversion came pre-installed on Tiger or not, but I know for a fact that it does come as a standard component on Leopard. This is great news.

One small issue, though, is that there is not a way in the OS X UI to have Subversion start up when your computer boots up. This tutorial will help you set up a launch daemon that will fire up Subversion silently when your computer boots up.

Before we begin, you’ll need to make sure you have enabled root access on your machine. In Tiger, follow these instructions. In Leopard, follow these instructions instead.

Step 1: Create a Start-up Item

Open up your favorite text editor and paste the following into an empty document:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
  <key>Label</key>
  <string>org.tigris.Subversion</string>
  <key>Disabled</key>
  <false/>
  <key>OnDemand</key>
  <false/>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/svnserve</string>
    <string>–daemon</string>
    <string>–root</string>
    <string>/usr/local/svn</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>ServiceDescription</key>
  <string>Subversion Server</string>
  <key>StandardErrorPath</key>
  <string>/dev/null</string>
  <key>UserName</key>
  <string>root</string>
</dict>
</plist>

Step 2: Locate your repository

On line 16 of the plist file, you’ll find the string “/usr/local/svn” which points to the default repository location. If you have installed your repository in a different location, change the contents of this line to point to your repository. For instance, mine is on a separate drive, so my line looks like:

<string>/Max/SVN_Repository</string>

Step 3: Save the File

Save this file as (or move the file to) /Library/LaunchDaemons/org.tigris.Subversion.plist.

Step 4: Set Permissions

If you try to launch the daemon at the moment, you’ll get a “dubious permissions” error. To correct this problem, you’ll need to change your permissions.

In your terminal, type:

cd /Library/LaunchDaemons/
sudo chown root:wheel org.tigris.Subversion.plist

You’re done! Reboot your computer and test that your SVN server is running as expected.

By default, the root account is disabled in OS X. If you are a developer new to the platform, you will be needing to access many things that are available only with root access. This tutorial walks you through the process of enabling the root account in Leopard (OS X 10.5).

NOTE: This guide is specific to enabling root access on Leopard, (10.5). To learn how to enable root access on Tiger (10.4), follow these instructions instead.

Enabling Root in Leopard:

1. Open the Directory Utility: In the Finder, navigate to the Utilities folder (tip: click on the desktop, hit Cmd+Shift+U).
2. Click on the padlock to allow edits.
3. Go Edit > Enable Root Password
4. Enter and re-enter your password.

Now, you are set to access protected areas of the system via the terminal.

I’m an avid user of Google Reader to handle my two dozen or so feeds. Among my favorites are Boing Boing and CNet. However, I’m thinking of removing them from my list.

Why? They all publish too many stories to possibly keep up with. Which begs the question: how many updates per day is too many?

In the case of CNet, there have been days when they’ve published over 100 stories. My thesis is that this information overload results in an unused feed, making users drift away from your site.

For an RSS feed to be effective, 10 updates a day seems to be the magic number. This is opinion, not fact, but I would imagine that I’m not the only RSS consumer who feels that the sweet spot is somewhere south of a ten-spot.

This assumption is based upon the belief that a feed shouldn’t be a fire hose of information, but rather the delightful stream of mountain spring water that is the distilled information you care about. (Forgive me. I just can’t help myself sometimes.)

So what can be done if you’re developing a content rich site that will be updated dozens of times a day? My typical solution for clients is to provide a variety of granular feeds that filter the content such that feeds have no more than 10 updates a day.

Take, for example, Boing Boing’s iBag feed. What would be great is a set of specialty feeds that filter out, say, all stories on Steampunk, old scans of magazines, or Xeni’s long travelogues. What would be left are the few nuggets of info I actually care about.

Looking at one of my own sites, McKinneyNews.net, we offer a ton of RSS feeds. You can drill down by sport, school, writer, or any combination thereof. This reduces the total number of daily updates to a digestible number.

Another good example is Wired’s menu of choices. You can drill down by subject and author. They even allow you to create your own custom feed based on news you care about.

These examples share one thing in common: they let the reader scan and consume content they care about rapidly. This creates a stickiness that makes your site a part of your reader’s daily info diet, which is good for your client and good for your business.

Ages and ages ago when I started coding for the web, I read somewhere that it was more secure to keep the file containing your password and sensitive variables outside of the public web root. I’ve always taken this as law, and I’ve jumped through all kinds of hoops to structure my sites and framework in this manner.

But is it necessary? I’d love your thoughts on the matter.

For Dreamweaver users, this is important for two reasons: 1) the Connections folder is placed automatically in your site definition’s file root, and 2) Dreamweaver freaks out and breaks in all kinds of new and interesting ways when the file root and the public web root are not the same.

If I’m jumping through all of these hoops unnecessarily, I’d like to do something about it and stop banging my head against a wall.

To clarify what I mean, let’s take a linux install where the home directory is “/var/www”, and the public web is served from “/var/www/html”. In this case, you’d set the Dreamweaver file root to “/var/www”. Thus, the Connections folder is kept outside the public web root. In theory, there’s no way this folder could be hacked through human/webmin error (forgetting to turn off apache indexing, for instance), or through some other means.

So my question to you, my loyal readers, is whether this is necessary. What are the implications to keeping the Connections folder inside the public web root? Do you consider this to be dangerous, or am I worrying unnecessarily?

Thoughts? Discuss.

If you are a web developer, you undoubtedly have needed to edit a system config file from time to time. Your choices in the terminal are nano, and …well, nano. If you happen to have BBEdit installed, then you can use that as well. However, BBEdit costs $125, which is pretty steep if you just need a text editor.

Yee-ha! (sorry. I couldn’t help myself. I am from Texas, y’all). Turns out that BBEdit has a little brother called TextWrangler that has the advantage of being both free and powerful. Me rikey things that are free.

First, download TextWrangler from the Bare Bones Software site.

Next, when you install it, be sure to say ‘yes’ when asked if you want to install the command line tools. This integrates TextWrangler with the Terminal so that you can launch from the command line. Let’s say you want to edit your hosts file. You’d simply type:

sudo edit /etc/hosts

It’s that simple.

Now, let’s Automate this for frequently edited docs such as your Apache config or hosts files. Launch Automator and create a new, Custom workflow.

Add a Run AppleScript action. Enter the following:

do shell script "sudo edit /etc/hosts" password "[YOUR ROOT PASSWORD]" with administrator privileges

Save the workflow as an application. Now, you can edit these protected system documents with ease.

Tip: Use QuickSilver to launch your Automator script with a few keystrokes.

Enjoy.

Recently, I wrote a Step-by-Step guide for installing a basic development server on Mac OS X Leopard (10.5) using the built-in packages. It turns out that the version of PHP that is packaged with Leopard is missing many commonly used components such as the GD Library, MCrypt, and many others. Since recompiling PHP on Leopard is no small feat even for experienced developers, you may be looking for an alternative method to get your web server working.

This is where MAMP comes in handy. This tutorial will walk you through the steps necessary to get MAMP set up on your site, migrate your existing data, and set up multiple virtual hosts.

Revision Notes 02/03/08: Several readers have kindly pointed out some errors in the guide that follows. I’ve updated this article to correct some (all?) of these mistakes/omissions.

MAMP

MAMP (Macintosh, Apache, MySQL, PHP) is a tool released by a German company called living-e. MAMP comes in two flavors: free and Pro. The pro version is not free (appx. $70 at the time of this writing), but offers a bunch of convenient power tools to help you configure virtual hosts, your Apache server, and your startup items.

However, with a few simple tweaks to the httpd.conf, php.ini, and hosts file, the free version of MAMP should be more than adequate for most developers.

Overview

This tutorial can be used whether you are installing a web server for the first time or are migrating from Tiger (10.4), or have set up a default installation on Leopard. Steps aimed at migrating your data and settings are labeled with an “optional” tag.

Step 1: Enable your root password

1. Open the Directory Utility: In the Finder, navigate to the Utilities folder (tip: click on the desktop, hit Cmd+Shift+U).
2. Click on the padlock to allow edits.
3. Go Edit > Enable Root Password
4. Enter and re-enter your password.

Now, you are set to access protected areas of the system via the terminal.

Step 2: Export your existing data (optional)

If you were running a web server previously, you’ll want to transfer your data and settings. The best way to get your MySQL data is to use the MySQL Administrator tool to backup all of your databases.

1. Download and install the MySQL GUI Tools. You’ll only need the Administrator tool, but the others are good to have as well.
2. After installing the package, open MySQL Administrator.
3. Connect to your existing database(s).
4. Click the “Backup” tab and run a backup routine to save your database as sql dump file on your local drive.

Alternatively, you can use phpMyAdmin to export your data if your database is under 2mb (typically). I found this method to be unusable for large databases, however.

You can also use the mysql dump command line tool. This effectively creates the same dump file as the Administrator Tool, but is not nearly as easy and foolproof to use.

Regardless of the method you choose, you should have one or more sql files ready to be imported.

Why not just copy the data files? After many, many attempts to do this, I was unable to end up with a running database, even after trying to preserve permissions.

Step 3: Save your existing settings (optional)

If you have previously set up your own server, you are likely to have settings you want to preserve. You’ll need backup copies (or access to) the following files:

• httpd.conf
• httpd-vhosts.conf (Apache 2)
• httpd-userdir.conf (Apache 2)
• php.ini
• hosts (Leopard, Windows, or *nix; Tiger & previous OS Xes used Net Info and don’t use a hosts file)

Step 4: Shut down built-in servers

If you have installed and configured Web Sharing and a MySQL database on your machine, we’ll need to ensure these are shut down before proceeding. If you have not, then skip to the next step.

1. In your System Preferences > Sharing control panel, uncheck Web Sharing
2. If you have MySQL installed, in a terminal window, type the following to shut down the existing MySQL server:

   sudo /usr/local/mysql/support-files/mysql.server stop

3. In a terminal window, type the following to remove any previous MySQL start-up items:

   sudo rm -R /Library/StartupItems/MySQLCOM

Step 5: Download and install MAMP

1. Go to the MAMP web site and download the MAMP package.
2. Extract and mount the dmg package. Drag MAMP (not MAMP Pro) to your Applications folder.
3. Go to /Applications/MAMP and launch the MAMP Control Panel.
4. Start the servers by clicking the “Start Servers” button.
5. Do not change any of the settings at this time. Just run defaults for the moment.

Step 6: Test your installation

Click on the “Open Start Page” button. This should launch the MAMP start page.

Congratulations. You have a perfectly fine web server running on your machine. This may be fine for some people—in which case, you’re done—but web developers are going to need to tweak a few settings.

You’ll notice from your URLs that you are running on an unusual port number (8888). This is fine for the time being, but you’ll probably want to switch to the default ports to avoid having to tack on “:8888″ to every local domain.

To make changes, let’s shut down the server by clicking the “Stop Servers” button.

Step 7: Switch to HTML & MySQL default ports (optional)

1. With the MAMP Control Panel still open, click the “Preferences…” button.
2. Click the “Ports” tab
3. Click the “Set to default Apache and MySQL ports” button to change the Apache port to “80″ and the MySQL port to “3306″.
4. Click Ok.

Step 8: Transfer your existing settings (optional)

MAMP keeps its config files in the Applications/MAMP/conf/ directory.

There are a million ways to get your settings over from your old server, including simply tweaking the settings by hand. I find the safest way to do this is to use a file comparison tool like the FileMerge tool included with XCode (included on your Leopard disc) to transfer settings surgically from your old server to your new one.

Regardless, this is the time to move your settings over if you want to customize your installation. Be careful here. This is the most common way to screw things up.

Step 9: Import your existing data (optional)

If you exported your data in Step 2, you’ll want to import them to your new MySQL server. The best way to get your MySQL data is, again, to use the MySQL Administrator tool to backup all of your databases.

1. Connect to your existing database(s).
2. Click the “Restore” tab. Select the file(s) saved in Step 2 to reconstruct your database(s).

Alternatively, you can use phpMyAdmin’s import tool.

Step 10: Install PEAR (optional)

PEAR is a companion to PHP that is typically installed by default along with PHP. PEAR is a set of applications, modules and pre-packaged classes that provide a wealth of functionality to your apps with minimal effort. One example covered on this blog is how to implement an elegant caching mechanism with just a few lines of code. Using PEAR is highly recommended.

If you do not already have PEAR installed, type the following in a terminal window:

curl http://pear.php.net/go-pear > go-pear.php
sudo php -q go-pear.php

This will auto-install and pre-configure PEAR for you.  Accepting the defaults during the installation should be fine for most users.

Now, we need to tell MAMP’s version of PHP to look for the PEAR files. To do this, we’ll need to modify the php.ini config file installed by MAMP. First, back up the config file by typing the following in a terminal window:

sudo cd /Applications/MAMP/conf/php5/
sudo cp -p php.ini php.ini.bak

Now, edit the php.ini file, open “/Applications/MAMP/conf/php5/php.ini” in your favorite text editor.

Scroll down to the include_path directive and change the following [» shows line wraps -Ed.]:

FROM:
include_path = “.:/Applications/MAMP/bin/php5/lib/php”TO:
include_path = »
“.:/Applications/MAMP/bin/php5/lib/php:/usr/share/pear”

Step 11: Set up your first virtual host (optional)

Virtual hosts are Apache’s way of letting you serve up multiple sites on a single server. Name-based virtual hosting is a convenient way to do this.  Not everyone needs to set up a virtual host.  For instance, if you are just tinkering on a single site, then you can skip this step.  However, if you are developing and testing multiple sites locally, you will need to do this step.
For this example, we’re going to set up a test site called “site1″. With a name-based virtual host, all we’d type in is “http://site1/ “.

In order to make this work, we’ll need to edit the hosts file on your machine. (Note: In Tiger and previous versions of OS X, you accomplished this through the NetInfo dialog. Since the NetInfo dialog was killed in Leopard, we do this the same way you do this for *nix and Windows by editing the hosts file directly).

To edit your hosts file, type in the terminal:

sudo nano /etc/hosts

Below the default entries, you’ll add the following:

# My sites
127.0.0.1 site1

The following is a screenshot of my hosts file.  Yours will be similar but different:

Save your changes.

Now, we’ll need to add a corresponding virtual host. But first, Apache wants us to add our existing default directory as the very first virtual host. This is critical, so do not skip this step.

To edit your virtual hosts file, open “/Applications/MAMP/conf/apache/httpd.conf in a text editor.

Uncomment the virtual host directive:

NameVirtualHost *

Replace the two example virtual hosts with the following:

<VirtualHost *>
DocumentRoot “/Applications/MAMP/Library”
ServerName localhost
</VirtualHost>

Next, add your first virtual host similar to the following:

<VirtualHost *>
ServerName site1
DocumentRoot /path/to/site1
</VirtualHost>

This is a screenshot of the vhosts section of my http.conf file.  Yours will be similar but different:

Who do we have to add our default directory first? According to the Apache Docs on Virtual Hosts, they recommend the following:

If you are adding virtual hosts to an existing web server, you must also create a <VirtualHost> block for the existing host. The ServerName and DocumentRoot included in this virtual host should be the same as the global ServerName and DocumentRoot. List this virtual host first in the configuration file so that it will act as the default host.

Note: Failing to add my default directory as the very first virtual host tripped me up for days. If your virtual hosts are defaulting to an unexpected directory, this is likely to be the culprit.

Step 12: Restart the servers

Back in the MAMP Control Panel, click the “Start Servers” button to restart Apache and MySQL with your new settings. Fingers crossed, everything went well, and you can now access your local test sites.

If something went wrong, retrace your steps. The most likely cause is a mis-configuration in your Apache config file. To check the syntax of your conf file, type the following into a terminal window:

cd /Applications/MAMP/bin/apache2/bin
sudo ./apachectl -t

Repair your config file as necessary.

Step 13: …

There is no step 13. I just didn’t want to end on a bad number.

Step 14: Create a startup item

Now that you have everything running, you’ll probably want to launch the web server on start up. One of the nice things about MAMP Pro is its built in ability to start itself up on login. The free version of MAMP does not have this luxury, but this is easily solved with Automator.

1. Open the MAMP Control Panel.
2. Click Preferences
3. Click the Start/Start tab
4. Check “Start Servers when starting MAMP”
5. Un-check all other check boxes, including “Stop Servers…”
6. Click OK to save your settings. Close the control panel.
7. Open Automator
8. Create a new, empty workflow.
9. Add the “Launch Application” item.
10. Add the “MAMP Control Panel” as the launched app
11. Add a “Pause” item and set it to last for 10 seconds. This will give MAMP time to launch the servers even if your drive is being taxed during startup.
12. Add a “Quit Application” item, again setting MAMP as a target.
13. Save the workflow as an Application.
14. Open System Preferences > Accounts > [Your account]
15. Click on the “Login Items” tab.
16. Add the Automator workflow you just created to your list of startup items.
17. Uncheck the newly added workflow to hide it during launch.
18. Save your settings and restart your machine to test everything.

The one drawback to this technique is that you’ll be asked for your root password every time you launch your machine.

Note: I attempted to add the start up scripts used by MAMP directly, but had no luck in launching the MySQL server this way. If anyone knows of a way to do this, feel free to add your comments below.

Conclusion

By this point, you should have a fully functional development server that you can extend and expand as you take on new projects.

Please feel free to add comments below if you find errors or problems with the guide above.

Good luck.

The most excellent web site, A List Apart, has published the results of their 2007 Web Design Survey.

This is far more than a simple web poll. Instead, the survey compiled responses from over 33,000 designers and developers. The results are very interesting and worth a download.

One of the great advantages of developing web sites on a Mac is the fact that all of the tools you need to run a web server are pre-installed. Getting them to work and play well together requires a little work—especially in Leopard.

If you are simply wanting a web server to host your personal web site, then you might want to consider stand-alone, point and click apps like XAMPP and MAMP. These turnkey solutions set everything up for you and are great solutions if you are just starting or have simple needs.

However, if you want to set up a development environment running multiple test sites using the free tools already installed on your Mac, and you aren’t afraid of the terminal, then read on.

UPDATE: Since posting this tutorial, I have learned that the stock installation of PHP does not include several critical libraries. After several days of experimenting, I finally landed on MAMP as my production solution. I have published a walk-through for setting MAMP up on your machine [link].

NOTE: This guide is specific to getting a server running on Leopard 10.5. Earlier versions of the OS are not covered here.

This guide will walk you through the steps needed to get a development environment set up and running on your copy of Leopard. In this, we will do the following (click on each to jump to the corresponding section):

1. Enable your root password
2. Install the Xcode Tools
3. Edit your Apache configuration file
4. Set up your first virtual host
5. Start/Restart Apache
6. Test Apache
7. Test PHP
8. Load MySQL
9. Install phpMyAdmin
10. Install PEAR

Overview

A commonly used web server solution consists of 3 major components: Apache web server, a MySQL database, and the PHP scripting engine. This is the "AMP" in LAMP. (The "L" is "Linux"). This set up is widely used in the development community for two reasons: 1) it’s free and open source, 2) it’s very mature. "AMP" components are included in every copy of OS X, but getting them to work requires a few steps.

Step 1: Enable your root password

1. Open the Directory Utility: In the Finder, navigate to the Utilities folder (tip: click on the desktop, hit Cmd+Shift+U).
2. Click on the padlock to allow edits.
3. Go Edit > Enable Root Password
4. Enter and re-enter your password.

Now, you are set to access protected areas of the system via the terminal.

Step 2: Install the Xcode Tools

While this isn’t strictly necessary, it’s good practice for developers to install the Xcode tools provided for free on your Leopard disc. You’ll need it at some point, so go on and install it.

1. Insert your Leopard DVD
2. Navigate to Optional Installs > Xcode Tools > XcodeTools.mpkg
3. Run the installer.
4. Go get a cup of coffee.

Step 3: Edit your Apache configuration file

Note: throughout this guide, you will need to edit configuration files. There are several ways to do this. My preferred method is to use an app called BBEdit that allows you to edit protected files more gracefully than, say, TextEdit or the terminal window. However, BBEdit is not free. For the purposes of this tutorial, I’m going to stick with the terminal method that uses the editor called "nano" just because it’s included on every system.

In the terminal, type:

sudo nano /private/etc/apache2/httpd.conf

Note: "sudo" is a command that lets you perform a specific task with root privileges without having to log in as the root. This is the recommended method of mucking about in the terminal as it is safer than being logged in as root.

1. Scroll down to about line #114. You’ll see the following:
   #LoadModule php5_module      libexec/apache2/libphp5.so

2. Remove the hash mark as follows:
   LoadModule php5_module       libexec/apache2/libphp5.so

3. In order to run multiple sites on this server, you will want to use virtual hosts. Scroll down to the bottom of the document (about line #461) and remove the hash from the Virtual Hosts entry as follows:
   Include /private/etc/apache2/extra/httpd-vhosts.conf

4. Exit and save httpd.conf.

Step 4: Set up your first virtual host

Virtual hosts are Apache’s way of letting you serve up multiple sites on a single server. Name-based virtual hosting is a convenient way to do this.

For this example, we’re going to set up a test site called "site1". With a name-based virtual host, all we’d type in is "http://site1/ ".

In order to make this work, we’ll need to edit the hosts file on your machine. (Note: In Tiger and previous versions of OS X, you accomplished this through the NetInfo dialog. Since the NetInfo dialog was killed in Leopard, we do this the same way you do this for *nix and Windows by editing the hosts file directly).

To edit your hosts file, type in the terminal:

sudo nano /etc/hosts

Below the default entries, you’ll add the following:

# My sites
127.0.0.1 site1

Save your changes.

Now, we’ll need to add a corresponding virtual host. But first, Apache wants us to add our existing default directory as the very first virtual host. This is critical, so do not skip this step.

To edit your virtual hosts file, type in the terminal:

sudo nano /etc/apache2/extra/httpd-vhosts.conf

Replace the two example virtual hosts with the following:

<VirtualHost *>
  DocumentRoot "/Library/WebServer/Documents"
  ServerName localhost
</VirtualHost>

Next, add your first virtual host similar to the following:

<VirtualHost *>
  ServerName site1
  DocumentRoot /path/to/site1
</VirtualHost>

Who do we have to add our default directory first? According to the Apache Docs on Virtual Hosts, they recommend the following:

If you are adding virtual hosts to an existing web server, you must also create a <VirtualHost> block for the existing host. The ServerName and DocumentRoot included in this virtual host should be the same as the global ServerName and DocumentRoot. List this virtual host first in the configuration file so that it will act as the default host.

Note: Failing to add my default directory as the very first virtual host tripped me up for days. If your virtual hosts are defaulting to an unexpected directory, this is likely to be the culprit.

Step 5: Start/Restart Apache

1. If you haven’t done so already, go Apple Menu > System Preferences > Sharing
2. Ensure that “Web Sharing” is checked

Tip: To restart Apache in the future, you can come to the same control panel, uncheck and recheck the Web Sharing item.

Tip: Alternatively, you can type the following into a terminal:

sudo /usr/sbin/apachectl graceful

Tip: Alternatively, you can create an Automator script as follows:

1. Open a new, blank, custom workflow
2. Add a “Run AppleScript” action.
3. Type the following, replacing values as necessary:
   do shell script “sudo /usr/sbin/apachectl graceful” password “[YOUR ROOT PASSWORD]” with administrator privileges
4. Save the workflow as an Action.

Step 6: Test Apache

In a browser, load your localhost: http://localhost

If you see the default Apache home page (which contains a red and blue feather image), your Apache server is set up correctly. If you do not, then you might try checking your Apache config syntax:

sudo apachectl -t

Step 7: Test PHP

In your favorite code editor, create a new php file and call it "info.php". In this file, enter the following code:

<?php phpinfo(); ?>

Save the file to the root of your local host directory (e.g. "/Library/WebServer/Documents/info.php") directory. In your browser, navigate to the file (e.g. "http://localhost/info.php").

You should see a purple and white table containing all the PHP variables, modules, and settings. If you don’t see this table, backtrack to Step 3 above to ensure you’ve enabled PHP in your Apache config file correctly.

Step 8: Load MySQL

1. Download and unzip the MySQL Package for Mac OS X.
2. Install the main MySQL installer.
3. Install the Start Up Script.

As of this writing, MySQL has not been updated to support Leopard. You will be downloading the package for Tiger (10.4) and making the following modifications:

1. Do NOT install the MySQL control panel. As of this writing, it does not work with Leopard.
2. Start MySQL manually by typing the following into a terminal:
   sudo /usr/local/mysql/support-files/mysql.server start

MySQL should now be running silently in the background.

A new issue with Leopard’s installation of PHP is that it expects MySQL to be somewhere other than where it is installed by the package. To fix this, we need to create a new MySQL configuration file. To do this, create a text file and save it as "/etc/my.cnf". Enter the following text:

In a terminal window, type the following in order to create a folder where the MySQL sock file will live:

sudo mkdir /var/mysql
sudo chown _mysql /var/mysql

Note: If you are using any of the MySQL Tools (e.g. MySQL Administrator, etc.), you’ll need to tell them where to find the sock file. To do this, click the Advanced drop-down on the connection dialog, and enter “/var/mysql/mysql.sock“.

At this point, you should have a fully functioning database. Now, let’s get some data in there.

Step 9: Install phpMyAdmin

phpMyAdmin (PMA) is a popular and free tool to manage your MySQL databases. It is an integral part of most LAMP development environments.

1. Download and unzip the latest stable release of phpMyAdmin.
2. Copy the files to a directory of your choice. For this example, we’ll install it in "~/Sites/phpmyadmin/".
3. Per Step #4 above, add this directory as a virtual host called "pma".
4. Restart Apache to initialize your new virtual host.
5. Follow the installation instructions provided in the PMA download to set up the config file.
6. If you can navigate to PMA (e.g. "http://pma", you’ve good to go.

Step 10: Install PEAR

PEAR is a companion to PHP that is typically installed by default along with PHP. PEAR is a set of applications, modules and pre-packaged classes that provide a wealth of functionality to your apps with minimal effort. One example covered on this blog is how to implement an elegant caching mechanism with just a few lines of code. Using PEAR is highly recommended.

In a terminal window, type the following:

curl http://pear.php.net/go-pear > go-pear.php
sudo php -q go-pear.php

This will auto-install and pre-configure PEAR for you.

Now, we need to tell PHP to look for the PEAR files. To do this, we’ll need to modify the php.ini config file. First, copy the default config file and rename it php.ini by typing the following in a terminal window:

sudo cp /etc/php.ini.default /etc/php.ini

Now, edit the php.ini file:

sudo nano /etc/php.ini

Scroll down to line #469 or so and edit the include_path variable by removing the comment hash and adding the PEAR path as follows:

include_path = ".:/php/includes:/usr/lib/php:/usr/share/pear"

Restart Apache and ensure everything loads and runs as expected.

Conclusion

By this point, you should have a fully functional development server that you can extend and expand as you take on new projects.

Please feel free to add comments below if you find errors or problems with the guide above.

Good luck.

The old adage, “If it ain’t broke, don’t fix it,” applies when it comes to Leopard’s new Stacks feature. Stacks has been highly touted by Apple to be a boost to productivity:

Organize files in a neat stack on the Dock.
One click and the stack springs open,
revealing items in an elegant arc or an
at-a-glance grid. [link]

Nothing could be further from the truth. I believe that Stacks fails in every way to enhance productivity.

Illustration 1: Poor User Interface with Changing Dock Icons

1. The dock icon changes as the contents change (see above). From a UI perspective, this is a bad idea that simply works against the user’s ability to act without thinking. Instead, he/she must roll-over each Stack and read its name to differentiate it from the other Stacks in the dock.
2. The Stack, especially in grid mode, truncates file names (e.g. “My Scrip…s.txt”), making it nearly impossible to differentiate one item from next (see below).
3. An open Stack takes up far too much screen space (see below). The user just needs a hierarchical menu of file names, not preview-able icons.
4. The user can’t navigate into sub-folders, forcing her to open the Stack’s finder item almost invariably.
5. While Apple may consider the leaning stack to be “elegant,” the reality is that this makes it very difficfult for the user to quickly scan the folder’s contents.

Illustration 2: Unreadable, truncated file names and useless icons

In other words, the Stacks feature fails in every way to make it easy to click and select an item. The old method that let me dock a folder and right-click to view its contents was perfect. Why change something that wasn’t broken? The new Stacks feature may demo the OS well, but it is useless in a real-world production environment.

In the hope that David (one of Apple’s customers) can beat Goliath (Apple), I have written an open letter on this topic imploring Apple to bring back the old hierarchical menus for dockable folders from 10.4. If you agree with this letter, I encourage you to add your voice by commenting on it in the Apple forums.

[Update: 11/04/07 4:15p] The open letter described above was pulled from Apples Discussion Forums 42 minutes after it was posted. I’ve moved the Open Letter here. If you agree, feel free to post your comments below.

The following Open Letter was deleted from the Apple Discussion Forums 42 minutes after it was posted.

I understand the need to control your message and keep a lid on bad PR, but if this is a trend that continues, I think Apple is heading for trouble. Biting the hand of your customers–especially those of your evangelists–is no way to do business, in my humble opinion.

Dear Apple,

To be blunt, the new Stacks feature is useless. On behalf of the legion of users and fans who upgraded to Leopard, I implore you to give us the ability to turn off Stacks and return to the 10.4 method of docking folders.

There are several reasons Stacks fails as a productivity enhancer:

1) The dock icon changes as the contents change. From a UI perspective, this is a bad idea that simply works against the user’s ability to act without thinking. Instead, he/she must roll-over each Stack and read its name to differentiate it from the other Stacks in the dock..

2) The Stack, especially in grid mode, truncates file names (e.g. “My Scrip…s.txt”), making it nearly impossible to differentiate one item from next.

3) An open Stack takes up far too much screen space. I just need a hierarchical menu of file names, not preview-able icons.

4) I can’t navigate into sub-folders, forcing me to open the Stack’s finder item almost invariably.

5) The leaning stack forces me to tilt my head just to read and interpret its contents.

In other words, the Stacks feature fails in every way to make it easy to click and select an item. The old method that let me dock a folder and right-click to view its contents was perfect. Why change something that wasn’t broken? The new Stacks feature may demo the OS well, but it is useless in a real-world production environment.

Please provide an option to revert back to the 10.4 method.

Many thanks,
Steve Stringer
Web Developer
Dallas, TX