If you create any sort of training videos for your clients, then you’ve most likely been using Ambrosia’s excellent SnapzPro.

SnapzPro has been the mainstay of desktop capture for years, but it’s somewhat of a one-trick pony. It captures the desktop action very well, but it offers nothing in the way of editing capabilities. It also restricts you more or less to a small view window, and you basically had to do everything in one clean take or bring multiple clips into a video editor to bring everything together.

Now, we have ScreenFlow from Vara Software. This $99 Leopard-only app lets you capture your desktop just like SnapzPro, but it does a whole lot more.

For starters, you can capture your entire desktop and pan around in a cropped version for optimal output. You can even capture your mug via your iSight and edit this into your video to add some variety to your output. There are callouts and cursor effects that you can layer in after the fact–something you used to be able to do only at run-time with OmniDazzle. Finally, there’s the timeline where you can edit, trim and otherwise perfect your output for professional results.

ScreenFlow is a huge timesaver and lets you produce training videos of a quality that was previously possible only with an expensive video editing package and multiple “takes” with Snapz.

Get the free demo of ScreenFlow here. You’ll be able to do everything you need to evaluate the software, but any output will be watermarked. The demo is otherwise identical to the unlocked version.

I was listening to MacBreak Weekly 73 in which Merlin Mann mentioned a backup routine that he uses that takes the approach of rsyncing your entire drive every night for the day WHEN your main drive fails. He mentioned briefly that JWZ (a.k.a. Jamie W. Zawinski) recommended this method on his LiveJournal blog [link].

JWZ’s piece is both funny and helpful. It’s well worth a minute to read.

Now get those hard drives replicating!

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.

Cache Lite (or Cache_Lite) is a PEAR package that takes the pain out of server-side page caching. If you have a site with more than a moderate amount of traffic, or simply want to ease the server load rendering a particularly complicated PHP page, you should consider using this Cache_Lite.

Caching Overview

Let’s take the example of a real news site I built for a client, McKinneyNews.net. There is a lot going on on the front page: the main body has a story flow that is updated several times a day, blog posts are summarized as needed, and windows to other parts of the site (e.g. calendars & sports schedules) are shown via widgets in the sidebars. All of this dynamic content comes at a huge server performance penalty. Simply put, the home page is expensive to render.

This is where caching comes to the rescue. In the case of news and blog posts, these are updated several times a day, but certainly don’t need to be re-rendered with every page view. In fact, the front page changes perhaps a dozen times a day. Thus we do the heavy lifting in the back-end when content is published, not every time site visitors request the page. On heavy pages like this, caching can decrease load times and improve server performance dramatically.

Cache Lite

When looking for a caching solution, I was concerned with three things: 1) ease of implementation, 2) modularity so it could be used for blocks of content, not just entire pages, and 3) security.

Implementation couldn’t be easier. Simply install the Cache_Lite package (or request that your host install it for you). As a super-user in a terminal, type the following:

pear install Cache_Lite

Now you’re ready to start using Cache_Lite. A very good tutorial on the use of the Cache_Lite package can be found here, but the basic structure is as follows:

<?php
// Include the package
require_once(‘Cache/Lite.php’);

// Set a id for this cache
$id = ‘123′;

// Set a few options
$options = array(

    ‘cacheDir’ => ‘/tmp/’,
    ‘lifeTime’ => 3600

);

// Create a Cache_Lite object
$Cache_Lite = new Cache_Lite($options);

// Test if thereis a valide cache for this id
if ($data = $Cache_Lite->get($id)) {

    // Cache hit !
    // Content is in $data
    // (…)

} else { // No valid cache found (you have to make the page)

    // Cache miss !
    // Put in $data datas to put in cache
    // (…)

    $Cache_Lite->save($data);

}

?>

Since it is a rare case that an entire page is presented to all users identically (e.g. if the page contains a slug that welcomes a user by name), caching only parts of a page becomes a necessity. Instead of using the code above to draw an entire page, use it to draw only a portion of it (e.g. a news block), leaving the other, lighter portions of the page to be rendered dynamically with each page draw.

Likewise, let’s say that the block you want to cache can be drawn one of several, finite ways. Let’s take for example the case where only part of a story is shown to users who are not logged in, while the full story is presented to those who are. If you are not careful, you could cache the whole story and present the logged-in state page to users who are not logged in. The key here is to pick an $id that is unique and state based, and call it back based on that same state.

Finally, security: Cache file corruption because of concurrent read/writes is always a concern, but Cache_Lite takes care of this via hashing and checksums. If the data has been tampered at all or is incomplete due to a write-in-progress, live content is used.

In the time it has taken you to read this article (and thank you for doing so!), you could have Cache_Lite up and running on your site. It’s that simple. Read the documentation (it’s painless) and give it a shot. Your server and your users will thank you for it.

Back in the day, I produced video games for a living, so when I heard that sprites were a great way to improve site performance, I had to put my way-back hat on.

A sprite, if you don’t know, is a single graphic file that contains many elements used to display, say, tiles in your favorite side-scroller (Metal Slug, anyone?), or, in this day and age, background elements on a web site. Instead of displaying the entire file, only a portion of the graphic file is revealed. Fortunately, this is a simple thing to do with CSS’s background property.

The performance gains on a web site are achieved by grouping elements together to reduce the number of http requests made to the server. For each graphic element, JavaScript file, and CSS file on your web page, your browser makes a separate http request to the server, complete with browser info and a bunch of overhead crap that you don’t need. Combining, reusing, and reducing are the three keys to performance.

Excellent candidates for CSS Sprite optimization are gradient backgrounds, rollover-buttons, tab elements, or rounded graphic box elements. Creating a sprite is easy, but tedious. You’ll want to do this only once the design is locked, since going back and making changes can be a pain.

For the purposes of this article, let’s look at a recent example of how CSS sprites reduced page load times dramatically. TheFreelanceNation.com is a client site I did recently where the design was handed to me. The site consists of many rounded “gel” elements, each of which required 9 graphic elements.

By grouping all of the page elements into two files–one for the rounded corners, and another for horizontally repeating elements–the number of overall http requests dropped by almost 70% (120+ down to 35 or so). I was able to reduce this further by grouping and compacting JS files and CSS files, but that’s a topic for another day.

In Photoshop, open the elements you want to group together. Then add each to a master file, making sure to draw guides on the boundaries so you can easily measure the pixel locations later. The rule of thumb is to group elements that repeat together. Meaning if you have elements that repeat-x, you’ll group them in a tall file. Elements that repeat-y will go together in a wide file. Save this in an optimal file format (I find that 8-bit, PNG, difussion dithered is best for all but the most colorful sprite files, in which case 24-bit will do). Experiment in Photoshop’s Save for the Web dialog to get the best result.

Once you have your grouped file ready, adapt your CSS files as follows:

.orangeBG {
background:url('/images/sprites.png') repeat-x 0 0;
height:20px;
}
.greenBG {
background:url('/images/sprites.png') repeat-x 0 -20px;
height:20px;
}
.blueBG {
background:url('/images/sprites.png') repeat-x 0 -40px;
height:40px;
}


…etc.

Notice two things:

1) is the use of shorthand. The background shorthand syntax is “background:[url] [repeat] [xpos] [ypos]. While this isn’t strictly necessary, it makes things a lot cleaner.

2) the starting point of CSS element within the sprite is measured in negative pixels. (It took me a while to figure this one out.)

Play around with this. The technique is surprisingly simple once you get the hang of it, and the results can be stunning. You’ll find initial page loads to be faster, and subsequent cached reloads to be much snappier.

When I’m working in Code View, I have used Courier New. Until now.

My friends over at 43Folders tipped me off to this nice, free monospace font called Inconsolata that is excellent for use in code view, be it in Dreamweaver, TextMate, BBEdit, or whatever. The font, which is the creation of Raph Levien, is very readable and scannable. If you live in code view all day, or just want a very readable screen font, check out Inconsolata.

Yesterday, I discussed a technique to recover data if your database has gone <skrewed>poof</skrewed> using Google’s cached content. There’s another technique that has saved my bacon more than once: The Internet Archive’s Wayback Machine.

I once ran into a situation where the data on a new client’s server was corrupted, and there were no backups available. The graphics were jumbled or missing altogether, and the original artist was missing in action. Without the original source files, or any data backup to speak of, my client was pretty much pooched. And because the site had been in this state for quite some time, Google had cached the corrupted content. What to do? Visit the Wayback Machine, that’s what.

If you aren’t familiar with the Internet Archive, it is a non-profit that has been quietly taking periodic snapshots of the Internet–yes, the entire Internet–since 1996. Unless you have been one of the idiots who have requested that the IA stop
“stealing” your content, images of your site are probably in the Archive.

To use this technique, simply type your URL into the Wayback Machine’s search tool. You’ll get a list of snapshots in return that will, in most cases, date back to the birth of your site. Clicking on one of these snapshots should reveal a navigable (and, hence, content-extractable) version of your site as it appeared on that day.

In my case, I was able to find most of the images in an uncorrupted state. Simply by saving the graphics directly from the browser into my client’s site, I was able to reconstruct the site and get my client back on the web.

Catastrophic Data loss. It happens to the best of us. But thanks to the Power of the Interwebs, there really is no such thing as a total data loss. If you’re careful and resourceful, you can recover from even the worst data loss.

The Cobbler’s Kids Have No Shoes

On Friday night, I discovered something was very wrong with my site, including this blog. Long story short, despite my paranoia about backing up my data and making frequent archives of my client’s sites, I’m less vigilant about my own sites. To my horror, I found that the data for my very own site, including this blog, had reverted back to March. Meaning every post I had made to this blog for the past 6 months was just gone.

So how does one recover from such a disaster? This is where Google’s cached content comes in handy.

Google’s Cached Content

I was able to do a search for my site using Google’s “site:[sitename]” technique. Enter site:stringfoo.com by itself, and I get every single page that’s indexed by Google.

By clicking on the Cached link, I was able to bring up an archived copy of my site’s pages. Using this technique, I was able to find WordPress’ monthly archive pages, from which I was able to retrieve my post excerpts and titles. Using the titles, I was able to find the full articles. One by one, I was able to recover the posts with relative–if not tedious–ease.

While it certainly is not fun, it is a method of last resort to recover from a catastrophic data loss.

When integrating HTML support into Outlook 2007, MSFT chose to use the Word 2007 HTML rendering engine instead of the much more logical choice of IE7. As a result, Outlook 2007 can render only a small subset of the HTML standard.

Gone are the halcyon days of practical div support, background images, and many, many other mainstays of standards-compliant markup. Instead, we have to rely on the older and less elegant table-based layouts of old just to get our emails to look pretty.

There is an in-depth article published on the MSDN site, including a list of supported tags and a somewhat helpful Dreaweaver validator for Word 2007:

• MSDN Article: Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2)
• MSDN Article: Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2)
• 2007 Office System Tool: Outlook HTML and CSS Validator

Of course, the validator comes as an MSI (Microsoft Software Installer), which means that if you’re developing in Dreamweaver on the Mac, you’re SOL (Shit Out of Luck). There’s no reason for this other than corporate arrogance; the installer simply dumps two text files into a destination directory.

Which leads me to the work-around tip. If you have Parallels or VMWare (or any access to a PC), do the following:

1. Open a Windows VM (or otherwise use a PC)
2. Download the installer for the Macromedia validator (”WordMailSupportMacromedia.msi”)
3. Run the installer, but for convenience, have it dump the files in a temporary directory instead of the deeply nested default.
4. Now get the two recently “installed” files over onto to your Mac (”Word2007.txt” and “Word2007_CSS.xml”).
5. Paste them into ~/Applications/Adobe Dreamweaver CS3/configuration/BrowserProfiles
6. Restart Dreamweaver
7. (Back in Windows, run the installer again to uninstall the files and clean up the registry)

The Word 2007 validation profiles will now be available for use.

Have loads of fun with this one.

I admit it: I’m a Net Nerd (a professional one at that).  As such, I have dozens of sites that I frequent for both personal and professional reasons. Being security conscious, I have accumulated a mix of passwords and usernames. At last count, I had over a dozen passwords that I had to juggle in my head. Combine that with any of half-a-dozen usernames, and you can imagine that things eventually got out of hand. It finally got to the point where I was unable to log into any site without multiple attempts. Something had to be done.

I’ve developed a system that works incredibly well without sacrificing security. It employs three tools: 1passwd which handles login credentials in my browsers, TextExpander which handles passwords for non-browser apps like Terminal, and Lockbox.cc which stores passwords and other sensitive info securely on the web so I can access it from any machine.

First, 1passwd ($29.99 by Agile Web Solutions) is an excellent password manager and auto-fill utility for the Mac. (Sorry, Windows users. This one’s Mac only). 1passwd helps you by remembering your login credentials on a site-by-site basis. It’s smart enough to know what page it’s on and presents you with the credentials for that page. It even lets you save multiple credentials for the same page, which is extremely handy if you have multiple accounts on the same site (GMail, for example, or multiple test accounts on a site you’re developing). Finally, 1passwd stores this info in your keychain, so the most current info available in any browser at any time. Copying that keychain file from computer to computer allows you to extend 1passwd’s central utility across all of your computers.

So 1passwd covers login forms, but what about non-browser applications such as Terminal? Another strategy I employ is to use TextExpander to remember complex (and hence secure) passwords for root accounts. TextExpander, if you don’t know, is a must-have utility ($29.99 from SmileOnMyMac.com) that expands abbreviations as you type. It also makes those snippets available in your system’s toolbar, which is key to this tip. Since 1passwd doesn’t work in Terminal, I put the root password in a TextExpander snippet. When challenged for the password in Terminal, I simply select it in the TextExpander pull-down, and I’m good to go. This allows me to store any number of root passwords for any number of accounts.

(Note: I recognize that this technique requires storing your passwords in the clear in your TextExpander preferences, but if someone has hacked into your development system, you’re in a world of hurt for entirely different reasons.)

The final tool in my password arsenal is Lockbox.cc. This is a site I created (and which you are welcome to use) that allows me to store sensitive info securely on the web. This allows me to access this info from any computer, not just my development systems. For example, let’s say you just set up a site on a new host. The host typically sends you an email with your ftp login instructions, phpMyAdmin credentials, and other critical links. I save the relevant info in Lockbox.cc and I’m good to go.

So 1passwd is for daily use in my browser, TextExpander is for frequent use via Terminal, and Lockbox.cc is for archival and off-site access. Together, I’m able to use a variety of strong passwords and usernames without sacrificing convenience or utility.

Links:

• 1passwd - $29.99 @ http://1passwd.com, free 30 day trial
• TextExpander - $29.99 @ http://smileonmymac.com, free 30-day trial
• Lockbox.cc - Free! @ http://lockbox.cc