Posted on August 7th, 2010 No comments
If you have a Mac, chances are you love iPhoto. It’s probably the best program ever made for managing pictures. Now that your iPhone 3GS or iPhone 4 shoots video, you’ve got photos and pictures all mixed up together, and it’s not exactly easy to find the original photos on your hard drive. If you have a digital camera as well, like I do, then you have high resolution photos from your digital camera mixed in with lower resolution shots and videos from your iPhone.
Here are some power user tips and tricks for managing and backing up your iPhoto library. If you’re using Time Machine, your hard drive is backed up automatically, but what if you want to back up your iPhoto library to a memory stick to transfer to a digital photo frame? This is where a manual iPhoto backup can come in handy.
First question… Where does iPhoto store your original photos?
It’s not exactly obvious. Open your Pictures folder, under your home directory:
MacHD -> Users -> Your User Name -> Pictures
Inside your pictures folder, you’ll see a special icon named iPhoto Library. It’s actually an Application Bundle or Package, a special type of folder in Mac OS X.
Here’s Tip #1: Right click on iPhoto Library and choose Show Package Contents. When you do this, a new Finder window opens, and inside there you’ll see a folder called Originals. This is where all the goods are stored. Drag all the folders in here to a USB Hard Drive to backup your entire iPhoto library at any time.
Let’s say you have a backup hard drive named Backups, and on that drive is a folder called Movies. It would be great to separate out all the movies stored in your iPhoto library to this Movies folder. We don’t want to move them, because then iPhoto will lose track of them.
Here’s Tip #2: You can drag any folder from the Finder onto a terminal window to see its full path.
For example, to find the Unix path to the Movies folder on your Backups hard drive, you just drag that folder into a terminal and you’ll see that the path is
In Terminal, type
and press the spacebar.
Then drag the iPhoto Library’s Originals folder to the Terminal. Afterwards, the entire command will look something like this:
cd /Users/YourUserName/Pictures/iPhoto\ Library/Originals
Now press return, and you’ll be inside of the iPhoto Library/Originals folder from Terminal. Note that any spaces in folder or file names are preceded by a backslash (“\”) in Terminal.
Here’s Tip #3: Using the Unix find program, you can output your search results to a text file. Here’s how. At the terminal prompt, type:
find ./ -name *.MOV -print
This will show you (outputted to the Terminal window) all the movies under you iPhoto Library. What this command says is, find, under the current directory, all the files whose name ends with .MOV (yes, it is case sensitive) and then print it out (echo to the terminal window, not your printer.)
You should see a list of only movies, inside all the various folders under your iPhoto Library. What we really want, though, is to store these full movie paths to a text file, so we can reference them later. So, the way to do that is using the greater than symbol (“>”) and then provide the name of a text file to create. So the whole command to find movies and output the list to a text file goes:
find ./ -name *.MOV -print > ~/movies.txt
Now the tilde character (“~”), represents “my home directory”, so I’m asking Terminal to list all the movies under my iPhoto library, and save the output to a text file named movies.txt in my home directory.
Here’s Tip #4: How to copy all the files listed in a text file to a new location. The unix command “cp” stands for copy. But in order to do a batch copy, we need to write a little one-line bash script. We’re going to use our Backup drive’s Movies folder as the target directory to copy the movies to. The script looks like this:
while read file;do echo "$file";cp "$file" /Volumes/Backups/Movies;done <~/movies.txt
Depending on the speed of your hard drive, the size and number of movies you’re copying, this could take a while. Let’s look at the script piece by piece to see exactly what’s going on.
while read file;do ... done
This while loop says to continue reading lines from a file as long as there’s more lines in file to read. The end of the while loop is the done statement at the end.
This says to print (echo) the name of the file currently being copied to the terminal output window. Without this line, the script doesn’t look like it is doing anything… it still works, you just have no indication of what file is currently being copied.
cp "$file" /Volumes/Backups/Movies;
Here is the exact piece of code that actually copies the source file to the destination. Which source file? The one listed on the current line of the text file we’re currently reading from. Which text file?
This says we want to use our list of movies (movies.txt) in our home directory (~/) as the input file (<).
Thank goodness for great sites like unix.com where I found the inspiration for this post. I would’ve eventually figured it out, but their post saved me a ton of time and a lot of hassle. Hopefully this post will do the same for you, too.
Posted on July 16th, 2010 No comments
Thanks to this post on MacObserver, which explains you can make your terminal window semi-transparent. It helps, for instance, if you’re trying to type in some sample commands from a web browser in the background.
- Just go to Terminal -> Preferences -> Settings -> Window
- Click the background color chip
- Drag the opacity slider to the left.
Posted on December 3rd, 2009 2 comments
GMail is incredible, has been since it launched.
But if you’re not using the GMail Keyboard Shortcuts, you’re missing out. The performance of navigating GMail is instantaneous when using many of the keyboard commands, particularly archive (e) and delete (#).
Posted on November 3rd, 2009 2 comments
The latest Mac update, Snow Leopard, comes with pre-bundled with Apache 2.2, and PHP 5.3.
Here’s what I did to enable it and start making websites.
- Turning on Apache
To do this go to System Preferences -> click the checkbox by Web Sharing
- To check your Apache install
You might like this post about how to create a quick document for testing.
- Editing Apache Virtual Hosts
Paul Kukiel shares how to
- Turning on PHP
- Loading MySQL
Before you rebuild MySQL, double check your processor speed. If you upgraded to Snow Leopard from an older install on an older PPC or Intel Mac, be sure to know which processor type you need to build MySQL for. These instructions are for my Generation 5 Macbook Pro, not one of the brand new 64-bit models. Download the installer from MySQL.com. Then follow this post that shows how to build MySQL from source.
- Loading phpMyAdmin
- Using Terminal
- Turning on Apache
Posted on July 2nd, 2009 No comments
I just finished re-reading this post from a few hours ago and realized it has way too much detail and anecdotal information that most people aren’t going to want or need. What you need to know is the safest and easiest way to configure your staging server during a website redesign.
The goals are:
- Leave current website untouched while creating a new site at a staging URL
- Has to be easy to configure, reliable and repeatable at different ISPs
- Should require the least amount of effort & special skills to set up
- Should require the least amount of fiddling with your application code
- Should require the least amount of tweaking right at launch time
If you want to set up a staging server the easy way, here are my recommendations:
- Create a new hosting account based on the name of the main domain. DNS isn’t pointed to the staging server yet, but don’t worry about that. Chances are the new site will be avaliable at http://some.ip.ad.dress/~account/ but that’s ugly and not user-friendly.
- Add a parked domain to facilitate previewing, testing and approvals. Take advantage of the fact that a parked domain name can resolve to the staging server IP before the main domain is pointed. In essence, the parked domain is the staging domain and resolves to the staging server’s IP during and after development.
- Edit your local hosts file periodically to test the site at the main URL without having to change DNS entries at your provider.
- At launch, update the DNS for the main domain and point it to the IP of the staging server. There should be nothing more to do or configure differently because the web server was already programmed to serve the main domain in step 1.
Posted on July 1st, 2009 3 comments
So you decided to upgrade your website, redesign your site, or use the services of a new web guy. Since your existing website is still live on the internet, you want to keep your existing website live and untouched while you develop a new one on a staging server.
Any good web development company or website programmer should be able to explain how this process works. Perhaps they linked you to this post. Then again, this is not something that the average person under normal circumstances needs to do. Anyway…
In a nushell you have three options:
1. You can preview your domain at the new website’s IP address.
- Your web guy might be able to develop your new website at a static IP. If so, you can just browse that.
- That theory worked for the last several years, when you could devote a dedicated IP address to any site you wanted (most ISPs charge a buck or two a month for a static IP).
- Now that the net has run out of IP4-class IPs, nowadays you have to prove you need a static IP address (e.g. an e-commerce website needs a static IP for SSL Certificate installation) before they’ll just give you one.
- In short, your website may not be perfectly programmed to run at http://some.ip.add.ress/~newaccount/ although many do. For approvals and previewing purposes, emailing URLs around with numbers and funky characters in them tends to scare people. In short, in addition to being a little confusing, this may only be a viable option in certain circumstances.
2. You can register a domain name other than your main domain name, and point that domain name to your staging box as a parked domain.
- Parked domains are often called aliases, although aliases, or more accurately CNAME records are not exactly the same thing, which adds to the confusion. The shortest way to explain it is that if domainB.com is parked to domainA.com then typing domainB.com in a browser will bring up domainA.com. You can take advantage of how domain parking works during a redesign.
- For example, Salient Digital, Inc. has www.salientdigital.com for it’s main domain, so I register salientdigital.net. I create a hosting account on a new server on a different IP and create the account as salientdigital.com, but then add the parked domain, salientdigital.net.
- This way, I’m developing the new web application as and on salientdigital.com, according to the new server’s local dns. Nobody knows about salientdigital.net, including Google and the other Search Engines.
- For safe measure you can place a robots.txt in the root level with no index no follow, or even put an .htpasswd on the htdocs folder for added security.
- Once salientdigital.net is done and approved as the new website, I can point the DNS for salientdigital.net to the new (staging server’s) IP address… and no normal ‘launch’ is necessary.
3. You can hack your local DNS.
- This is the fastest and easiest way, but is the most technical as well.
- All operating systems (Mac OS X, Windows & Unix/Linux) have a “local hosts file”.
- Under Windows, this file is located in C:\WINDOWS\System32\drivers\etc\hosts.
- On Mac OS X and Unix systems, this file is located in /etc/hosts.
- Even though there is no .txt extension on this file, you can coerce your box to open it.
- Google how to edit hosts file for troubleshooting tips if you can’t find it or edit it.
- This solution overcomes the non-viability of option 1.
- How does it work? Why would I want to edit my hosts file?
- Your web developer will be developing your new site at some IP address.
- The server where this new account is set up knows how to serve it up, but you have to ask for it specifically. That is, if you make a request for salientdigital.com specifically to the ip address of the new/staging server, the server will know how to respond. The trick is requesting the old domain from the new server. To do this, we can hack our local hosts file.
- So the process goes like this:
- You type in http://salientdigital.com in your browser.
- The first place your system looks for where (the IP address of the Web Server) where that site might be located is the local system’s hosts file.
- If the server IP address is not in your hosts file, your system asks the DNS network for the location.
- If your local network doesn’t have a DNS entry for the domain you’re looking for, your ISP asks the DNS network on the internet at large for the server’s IP.
- So, the whole point of DNS is to map Domain Names to Server IPs.
- Adding an entry to your local hosts file is just instructing your computer exactly where a site is located so that it doesn’t need to check the Internet DNS system for the IP – you’ve listed it locally.
- Now, Ask your web guy to give you the IP address where your new site is being developed.
- Even if the IP is a shared IP address with an account name on the end of it, that doesn’t matter. It’s just how DNS works.
- Open your hosts file in a text editor, scroll to the end and press return at least once or twice, and then add the IP address, then some spaces or tabs, then the website domain name you are re-developing.
- You would enter something like
- where the first part is the NEW SERVER’s IP address, and the second part is the CURRENT/MAIN domain name.
- Save, and open a browser.
- Now, what happens next is magical:
- Browse to bbb.com and your new site will appear. You have to have the staging server set up as described above, using the main domain (bbb.com) for the account. (Adding a different parked domain as in Option 2 just makes it easier to pass around via email for approvals.)
- On your computer, and your computer computer only, and nowhere else on the internet, that hosts file tells your computer to look at the new server for the salientdigital.com home page. And the new server (at the new IP you put in your hosts file) returns it to you.
- 99.999% of the time, www.salientdigital.com will still resolve to the current, live, old website, while salientdigital.com (without the www.) shows the new site.
Once the new site is approved, the DNS record has been updated to the new IP (wait up to 48-72 hours for it to work worldwide… this is commonly called ‘DNS Propogation’ but it just means wait for a while)… you can go back into your hosts file and delete the line you added during development.
One thing to bear in mind is that you may need to tweak your web server settings, your ISP may not allow you to park domains before DNS is pointed, or your network administrator or ISP may be using a proxy server. Any of these can override your experience, so your mileage may vary. I’ve asked some ISP technicians about this before and realized I knew more about than they did. DNS can be screwy, so test from multiple browsers, different computers, clear your cache, when in doubt: reboot, Google it, backup your system first, etc. … All the normal precautions still apply.