The Dreamweaver team has been hard at work since the launch of CS3 to bring you…drum roll please…CS4!

That’s right! A bright and shiny new version is available as a public beta. Also available are the Bridge CS4, Fireworks CS4, and Soundbooth betas.

The biggest changes are in the interface.  The OWL interface that you’ve come to know and love in Photoshop are now in Dreamweaver, as are a host of other refinements and improvements.  My favorite UI enhancements by far are the Vertical Split View and Split Code View–the combination of which finally lets you work on the header and body of a document at the same time the way God intended. After all, why would she give us wide-screen monitors if she didn’t want us to see two pages side by side?

Also notable in the new Dreamweaver CS4 are the following:

• Javascript Extractor - provides an easy to make your JavaScript unobtrusive by externalizing it and tying it to watcher events.  This is very cool.  (Note: Read all about Unobtrusive JavaScript in this post.)
• Integrated Subversion Client - ties an SVN client into the site functionality.
• Related Documents - provides instant access to any file that is immediately linked from the document you’re working in
• New Spry Validation & Widgets - new and improved are the Spry validation widgets for passwords and radio groups, along with integrated support for the latest version of Spry.

Click the links below to get your copy hot off the digital presses:

• The Adobe Labs Dreanweaver Beta home

Please direct any feedback, bug reports, and feature requests to the Dreamweaver Public Beta Forums.

Safari 3.1 has been released for both the Mac and the Windows. The update is available via the automatic Software Update on the Mac, or via a manual update on Windows. Of course, you can download a fresh clean install here.

Included in the update is a new Develop menu which contains various web development features, allows access to the web inspector and the network time line, allows CSS editing in the web inspector, and allows user agent spoofing.

On the standards side, Safari 3.1 adds support for CSS 3 web fonts, CSS transforms and transitions, HTML 5 <video> and <audio> elements, offline storage for Web applications in SQL databases, SVG images in <img> elements and CSS images, and SVG advanced text. (Ironically, none of these things are standards yet, but whatever.)

The full release notes can be read here.

Since the launch of Leopard and Safari 3, I’ve been using Safari as my primary development browser. The only thing I miss from firefox is the ability to view the source code on selected text. Other than that, Safari 3 with the debug menu enabled has been the best browser for development on the market, hands-down. With 3.1’s update, this will only improve.

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.

A very good (and brief) blog post over at Signal vs. Noise [link]. Some choice quotes:

“Programmers often have difficulty going back to older code bases because they don’t reflect the latest, greatest idioms.”

“Even if you take that project from three years ago and scrub it clean as can be today, it’s still going to drift from the best practices of two years from now.”

“Here’s something I don’t say often: Suck It Up. If you work on more than a few projects, they can’t all smell like today’s fresh linens.”

I definitely recommend reading the whole post.

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!

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.

[Update 11-05] I’ve written a step-by-step guide that should help you set up your web server on Leopard.  Click here to read it.