What’s the Same

Here are the similarities between WordPress and Movable Type:

• A nice UI for the admin tool
• Easy to install on a remote server (more on this below)
• Logical template organization with a series of includes for easy maintainability

What’s Better about Movable Type

The Templating Language

While MT’s template syntax does take some getting used to, it’s very intuitive and thorough. Everything you can think of that you’d ever want to do on a blog is available. If you want to list the articles of a specific category, you simple use the category template tag, give it some attributes to customize the output, and it’s available. WordPress, on the other hand, makes you manage PHP loops. You have access to a variety of things, but you’re constrained to the current PHP loop you’re in. So if you want to show the last 10 articles for each category on any given page, you have to establish a new loop that provides access to that kind of data. It’s quite the maze of contexts, PHP functions, and attributes to customize those functions. I find Movable Type’s template tags to be much more intuitive and portable.

Static Publishing

This may not necessarily be a bonus to using Movable Type, but if your site is very popular and you want to run it on cheap, shared hosting, then static publishing is a great way to go. It essentially creates an HTML page for each article once when you publish your site. Thereafter, each time a user accesses an article, it is available without having to look anything up in a database. Unfortunately this feature is also MT’s downfall, which I’ll discuss next.

What’s Better about WordPress

Instantly Available Output

When you’re working on a new blog template (a.k.a. WordPress theme), and you tweak some markup and CSS, you simply have to refresh your browser and WordPress instantly shows the result. When doing the same thing with Movable Type, you have to republish your templates in the admin tool. To navigate to the correct page, click publish, wait, and then refresh your browser is a minimum of 5-6 seconds. Simply refreshing the WordPress page in your browser only takes about a second. Why would such a small amount of time matter? It depends on your development style, but I like to tweak n’ peek. I make a few small changes, then refresh in the browser to see how it looks. I repeat this process hundred, even thousands of times through the course of a template design. That really adds up when it takes 5 seconds longer to do with Movable Type.

Local Installation

You can get Movable Type to install locally on a Mac, but it’s not trivial (this article may help). Getting WordPress to run locally is just as easy as it is on a remote server. I really like being able to fully develop my template/theme locally and then just push it to the server when it’s ready. This saves a lot of time, especially with how much faster your local server is than a remote one.

Automatic Updates

In recent versions of WordPress (2.9+), upgrading to the next version of WordPress is fantastic. It only takes a couple clicks in your admin tool and it’s done. The same goes for plugins. Movable Type has hitherto been a lot more involved, and you have to get your FTP app out and rework things. More recent versions may have changed this, but I’ve been off Movable Type for almost a year now.

The Winner

Overall, I like WordPress better because of it’s faster theme development. When it comes to day-to-day blog use, they’re essentially equal, but when you build custom themes all the time, ease of development is a dispositive factor.

This works perfectly in Apache on my Mac, but I recently installed Virtualbox so I could test stuff in Internet Explorer. Referencing your local server from within Virtualbox hasn’t been exactly clear, and I found I had to use my Mac’s IP address and reference the Sites folder within the Home folder. The primary problem with this is that all the root-relative paths break because the URL in Windows doesn’t follow the same pattern. sl is much different than 10.0.1.2/~Clifton/Sites/sandlot.

After doing some research, I discovered a way to make Windows see my pretty little virtual hosts. Here’s how.

Access your hosts file here:
C:\windows\system32\drivers\etc

Edit that file with Notepad, and at the bottom, delete the line that has 127.0.0.1 on it, and add a new line for each virtual host you have like this:

10.0.2.2 name

The 10.0.2.2 is a default IP address that Virtualbox uses to reference your Mac (assuming you’re using the default NAT networking mode like I am), and the “name” is the name of your virtual host. So my full list looks something like this:

10.0.2.2 sl
10.0.2.2 clifton
10.0.2.2 cubs
10.0.2.2 labrum
10.0.2.2 labrums
10.0.2.2 lance


Now I can view local files instead of pushing things to a remote server in order for the paths to work. It also saves keystrokes as I can use the short names in Windows just as I do on my Mac.

Moving from one Gmail account to another is widely documented, but all the methods I found were unsatisfactory. Most suggest to use POP to pull all your email over to your new account. The fundamental problem is that you lose all your labels (Gmail’s version of email folders) and you would have to re-categorize all your messages. That’s just not acceptable.

I happened upon a tip that I explored further and it worked like a dream. To get started, all of the following must first be in order:

• You need to have both (old and new) Gmail accounts up and running, with IMAP enabled in both.
• You need a mail client that supports IMAP. I used Apple’s Mail. I hear Thunderbird works nicely as well.
• Ensure that both the old and new email accounts are set up and working in your mail client.

The gist of what’s happening here is that you copy the email folders from the old account into the new one. Your client then syncs those local changes with the server, and before long, all your email is the same between the two accounts. I have created a graphic to the right that should make it pretty clear what to do. Below are a few tips.

Do It in Chunks

I suggest doing a few folders at a time since it takes some time for Mail to sync it all with the server. I tried to sync my Gmail folders (All Mail, Drafts, Sent Mail, etc.) and the “All Mail” folder timed out after about 10,000 messages. So be sure to do it in slightly smaller quantities. If you have tons of email, it’s a good idea to start this task and then go to bed since it can take hours.

Don’t forget the Inbox

Be sure to also select all the emails in the inbox’s message list and move them to the new inbox. Don’t use the inbox folder, but grab the actual messages with a “select all” and drag them to the new inbox. They’ll move over and your old inbox should be empty afterwards.

Auto Responder and Forwarding

Once your email has been copied to the new account to your satisfaction, it’s a good idea to log in to the old account via the web client, and turn forwarding on to your new address. You can also set a vacation responder to tell people you have a new email address, and that they should update their records. This will spare you the task of spamming everyone you know with a notice that your email address changed.

There you have it. If you’ve got your eye on a new Gmail account, or you discovered how awesome Google Apps for Your Domain is, then don’t fear the email migration process.

The latest and rather unfortunate rumors suggest that Apple will be creating an “Explicit” category for app submission. I assume, gratefully, that this category can probably be blocked.

I decided to send Apple some feedback. Companies that make good choices should be praised and validated. Apple made a right choice, but likely due to pressure from salacious content providers, they are buckling and providing a new channel for such content.

Here is what I wrote to Apple:

I wish to applaud you for your recent efforts to remove the sexually explicit content from the App Store. This is a noble and praiseworthy thing to do.

Steve Jobs said in his keynote regarding the App Store that Apple would not allow porn. You have hitherto allowed yourselves to get sucked into the morally relative battle of what exactly is “porn”, and sexual content of varying degrees of offensiveness has crept into the App Store.

Rumors are now flying that you will be creating an “Explicit” category for such content. While I find this measure unnecessary (I believe the entire category should be precluded from submission permanently), I assume this will be something that can be voluntarily blocked by users.

There are diverse ways a person can consume sexual material. You need not taint your otherwise delightful App Store with such. I say do away with it entirely.

Thank you for your time.

Take the time to send Apple your viewpoint. Good things happen when lots of people speak up, and we need not be swayed by any perception that no one else feels the same way. Obviously enough people (probably parents of kids with iPod Touches) complained to Apple to initiate this in the first place.

Go tell Apple how you feel.

“Design is not just what it looks like and feels like. Design is how it works.”Steve Jobs, 2003 (source)

I bought a new Braun Pocket Go P-70 last year because it was for sale on Amazon for $10. I have mostly used Gillette razors, but I figured that since my current electric shaver was sprinting towards death, I’d try a new one. It sat in the packaging for quite some time under my sink in the bathroom, and I didn’t think too much about it. It came time for me to travel to UIE last fall, so I grabbed the new shaver and took it with me to Boston.

Using it was fantastic.

It solved all the gripes I’ve had with other shavers:

• Shavers come with a plastic cover for the cutter foil that always falls off and usually gets lost.
• Shavers have proprietary, built-in batteries that rarely hold a charge over the long-term, and require carrying a cable to charge it.
• Most shavers can’t get wet and you have to pull out a tiny little brush to clean off the blades.

The Braun Pocket Go does all of this right. You can run it under water to wash it, it uses two AA batteries (just changed my first set after 3 months of every-other-day use; my plug-in Remington barely lasted 3 weeks on a charge), and it has a cover that slides up to protect the foil. This is great product design.

There isn’t anything pretty or fancy about the aesthetics of this device. It looks mostly like every other shaver around. But obviously Braun stopped to figure out what was wrong with other electric shavers and they made it all right with the Pocket Go.

I’ll run with Steve’s quote and create my own:

Design is carefully considering what problems need solving, and creating a solution that meets those needs in a way that is enjoyable to use.

You’d think this is common sense by now, but there sure are a lot of lame products out there.

The fundamental reason for my switch is that I want my freelance business to be closely associated with my name. In the freelance design market, my experience has been that if you’re a one-man shop, you should try and look like one. Trying to fake that you’re a big firm, or even a small one, is a deterrent for most businesses shopping around for a designer. A business can usually get a better deal working with one guy instead of a firm with inflated pricing structures and lots of overhead.

FusionFox has always sounded cool and fast, but it has been a huge pain to brand over the years. I have spent days trying to come up with logos, and few things ever felt right. I also had a client mention that when talking about me and my business, the mention of “FusionFox” introduced confusion since it sounds similar to “Firefox.” So in the end, I wanted to be Clifton Labrum Design, and have a short, easy-to-remember domain name. I have registered a new LLC and am open for business. FusionFox will be no longer. I’ll keep the fusionfox.com domain for a while to make the transition smooth (it’s currently a 301 redirect to here).

There are lots of opinions out there on the superiority of .com/.net/.org and there’s no doubt that .com’s are the most valuable domains around. But have you noticed what’s happening with businesses these days? They have to come up with domains that are either really, really long, or somewhat complex in order to get an available .com. In my opinion, the domain extension is becoming less and less important in favor of either having a shorter domain (e.g. j.mp, bit.ly, tr.im, etc.) or a more personalized or understandable one (e.g. clifton.im). I don’t think the Internet community has winced one bit when it comes to international domains. URL shorteners are wildly popular now (thanks to Twitter) and I think those funky new domains show that having a .com is pretty irrelevant in a world where most URLs get clicked, not typed. I, for one, would much rather type greatcomputers.im than greatandaffordablecomputersystemsllc.com.

Having clifton.im is really easy to say, and hopefully easier to remember than FusionFox. I also bought clif.im and set up my own URL shortener. I’ve been pretty pleased to have both to establish and reinforce my online identity.

So welcome to clifton.im—home of my freelance web design shop. Don’t forget to grab the new RSS feed.

I know that many squatters have intentions of doing something great with their domain names some day, and just never get around to it. Others purchase them because they believe the foolish doctrine that all you have to do is buy a domain name and people will come running to you with huge amounts of cash to buy it. The odds of this happening are less than the odds of winning the lottery.

The Incorrect Categorization of Virtual Real Estate

I have made comments in the past that squatting should be regulated, and that there be requirements that you do something with a domain in order to keep it. Many snap back saying that this is anti-capitalistic and that domain real estate should be treated like physical real estate. They say that domain name value should be driven by the economic laws of supply and demand, and that if something is scarce, it becomes more valuable.

I don’t agree with this. Domain real estate is virtual. It is silly to think that domain space should be treated like real estate. The only way that comparison would be realistic is if there were an international committee who created land and sold it. That doesn’t happen on this planet. The real estate system exists because land is real, physical, and established. The supply of domain space is effectively infinite. Anyone who works with virtual hosts knows this is true. You can create new hosts indefinitely and use all kinds of names.

The Solution to Squatting

So this brings me to what I believe is the solution to domain name squatting. Domain names should always be cheap and there should be no limits in their creation. ICANN recently took a step forward by making it so a business could spend a couple hundred grand to have their own domain extension. For example, Apple could go buy .apple as an extension, and instead of using apple.com they could be www.apple or just apple. Then, as subdomains, they could create store.apple instead of store.apple.com. The only trouble with this move by ICANN is that it’s cost prohibitive to get your own extension. Only the rich can do it.

But if it were cheap, this opens up a huge number of possibilities for domains. If a squatter knows that people have millions of attractive domain name alternates, there will be less value in what they’re hoarding. The same rule of regulation I mentioned above would apply. If you bought the .labrum extension and didn’t do anything with it, then within a short period of time, ICANN should let me buy clifton.labrum as a subdomain. If you don’t use .labrum within a longer period of time, then I could buy .labrum outright.

Certainly there must be a lot of things I’m not thinking of here, and there are a lot of reasons to have the domain name system the way it is, but my basic point is that there should be a surplus of name space since its creation is cheap and limitless. Once this is the case, those millions of unused domain names would float back into availability and might actually get used.

Designing for yourself is a complex, frustrating process. I tend to think I’m one of those people that has good taste in web design. I can tell that what I’m making isn’t the greatest. I always wish it could be a little better and have something extra that’s going to make me love it. But after several design iterations, and several bouts with disappointment, I realized that I’m probably never going to love my work. I like it. I’m pleased with this design, but I don’t love it. I don’t feel like I’m going to change the design world with this, or suddenly gather thousands of design followers on Twitter.

I suppose it’s my appetite for design excellence that keeps me going. It makes me try harder and try repeatedly to be better, and to create things that more closely match what I know in my head is excellent.

To get this design from a point where I sorta liked it, to where I actually liked it, I had to try a lot of things. And for me, “trying” isn’t just whipping up ideas in Fireworks. I have to design them on a canvas, build them out in code, and play with the interface before I know I like it or not. Such a long gamut of idea validation requires time. Lots of it. So in the end, this little side project has been going on since last Spring (about 9 months ago).

I hope there are things I can learn about design and about myself that will make designing for myself a much faster process in the future, but I guess if it started to be easy, I’d lose interest in web design altogether.

Step 1: Create Google Calendars

Your Google Calendars (gCals) need to be ready to feed everything else. They are the source of the data. If you have everything in iCal right now, then do this:

• Before you do anything in iCal, back it up. Better safe than sorry.
• Create calendars in gCal to match the ones in iCal.
• Change your primary calendar in gCal to the same name as one of the ones you have in iCal.
• Export each iCal calendar as a .ics file to your desktop.
• For each calendar in gCal, you’ll need to import the corresponding .ics file from iCal. To do this, go to Settings > Calendars > Import calendar
• Import the .ics file and assign it to the corresponding calendar. Do this for each calendar.
• You should now see your calendar data in gCal. Yay!

Step 2: Add Calendars to iCal

Now it may seem counter-intuitive, but you’re going to delete all your calendars out of iCal. This is why we made a backup just in case. You should have a clean slate. We’ll now add each calendar from gCal into iCal one at a time as a separate account.

• Go to iCal > Preferences
• Go to the Accounts tab.
• Click the plus sign to add a new account.
• Put in the calendar name, your username (Gmail email address or your Google Apps email address), and your password.
• The Account URL is
  

  https://www.google.com/calendar/dav/you@gmail.com/user

  …for your primary calendar. For all the other calendars, it’s:

  https://www.google.com/calendar/dav/CALENDARID/user

  where CALENDARID is the funky ID found in the settings for each calendar. Go back to gCal, click on the calendar you’re adding (assuming it’s not the first, primary one, then copy and paste the ID down at the bottom. It’ll be a garbled mess, but it’s important. In the end, your Account URL will look something like

  https://www.google.com/calendar/dav/labrums.org_h3jjg5dsmkc1geclnnjf0oec28@group.calendar.google.com/user
  (this is all one string when you put it in, I just had to break the line so it fits on this website)

• Click Add and you’re all set. Repeat for each additional calendar using its specific Calendar ID as provided by gCal.

Step 3: Add Calendars to iPhone

At this point, you can just plug your iPhone in, open iTunes, go to the Info tab and tell it to sync all your calendars. The gCals should show up in the list. If you prefer to do it manually, continue reading.

This works much like it does in iCal. Before you begin, email yourself the Account URLs you used in the prior step with each individual Calendar ID. That way you can just copy and paste (w00t!) the URLs from Mail on your iPhone into the settings. This is much easier than typing them all out.

• Go to the Settings app.
• Select Mail, Contacts, Calendars
• Select Add account…
• Select the Other account type at the bottom.
• Then select Add CalDAV Account from the list.
• Put in www.google.com for the server, then your username, password.
• Put the calendar name in as the Description.
• In Advanced Settings, use SSL on port 443.
• Paste the Account URL from Mail that corresponds to this calendar.
• Repeat for each calendar you wish to add.

Once you have them all added, take a gander in the Calendar app. You notice that the colors are defined by gCal so go in there to pick the ones you want. Hopefully Google will eventually give us more granular control of these colors since I consider them to be rather drab. The good news is that the colors are consistent in all three areas: iCal, iPhone, and gCal. This is a great feature.

That’s all there is to it. You can go add an Exchange account to your iPhone now since you won’t need Google Sync anymore. In September 2009 with Snow Leopard, you’ll be able to add that same Exchange calendar to iCal. At that point, there will be nothing left to complain about in terms of the perfect calendaring configuration (or so I hope). Thanks for reading.

• Turning the servers on and off is buggy. Sometimes they fail to shut off when you restart your computer and the widget says they’re on when really they’re not. I’ve gone the rounds on the troubleshooting for this, and I have a decent solution but it takes a couple minutes each time I do it.
• The port numbers in the URL are lame: http://localhost:8888. Sure, you can use them to create virtual hosts (make Site A show up by typing localhost:5555, for example) but they are just noise. Why does that matter? I demo websites regularly, and I want the URL to look clean and organized. I guess I’m a picky designer.
• Along with my last point, I hate the idea of installing something extra when my operating system already comes with a solution. Using MAMP is a waste of the Sites folder and the Web Sharing feature on my Mac.

By using the built-in Mac OS X server, you use resources that are already available and are already on by default. It works great.

There are instructions all over the web about how to get the built-in server up and running on Mac OS X Leopard, but each phase of the process is on a separate site, and in some cases the documentation is too wordy and unclear. I’m going to attempt to give the instructions here in a short and simple fashion.

Step 1: Turn on Apache

Turn turn the Apache server on, simply go to System Preferences then go to Sharing.

Check the Web Sharing box in the list and shazam. Apache is on. You’ll notice in the same window that you can set what your computer name is. If you pick bob as your name, then in your web browser you would use bob.local to view your document root, which is the Sites folder found just under your home folder. (As you can see, I consider the Sites folder to be pretty important, so I dress it up from the default icon.) This window also tells you the IP address that other computers are use to see the contents of your Sites folder in a web browser. As long as you leave Web Sharing checked, your server is running. That means it starts and stops as you log in and out. It’s fully automatic.

Step 2: Turn on PHP

Mac OS X Leopard also comes with PHP 5.x so you just have to enable it. By default, it’s off (don’t ask me why). You’re going to need to edit the httpd.conf file for your Apache server in order to turn it on.

By default, you can’t see the httpd.conf file in Finder. It’s a hidden system file. To get to it, open Finder, go to up to Go and select Go to Folder… (or hit Command + Shift + G). Enter /private/etc/apache2 in the field and hit Go. There you’ll find httpd.conf. In order to edit the file, you will likely have to edit its permissions. Just Get Info on the file, click the little lock to unlock it (administrator password required) and give your user Read & Write permission. Then open it with your code editor of choice. On Line 114 you’ll see this:

#LoadModule php5_module libexec/apache2/libphp5.so

This is the function that fires up PHP. It’ll be commented out with a # so just delete that and you’re ready to go:

LoadModule php5_module libexec/apache2/libphp5.so

PHP is up and ready to go. You won’t have to do anything else. It’ll always be available. If you’re experienced with httpd.conf files, this is the one where you do all your magic for your OS X Apache server.

Step 3: Install MySQL

Go to the MySQL download page and find the one that says Mac OS X (package format). Download it. Once you have it, double-click the .dmg file to mount it. You’ll see two installer packages:

Double-click the mysql-5.x.x-osx10.x-x86.pkg one first. Go through the installation. If you get a “cannot install this software” error, just go back then click continue and you’ll be okay. It’s just a bug in the installer. Once that installation completes, double-click the MySQLStartupItem.pkg. Complete that installation. This one makes it so MySQL starts automatically when you log in to your computer).

The last thing to do is double-click MySQL.prefPane. This will install a little widget in your System Preferences that will allow you to turn MySQL on and off with a checkbox.

The last thing to do is interface with your database. If you don’t want to deal with the command-line, and you feel like puking every time you look at phpMyAdmin, then you can get a thick client that will let you manipulate your database. To do just that, I highly recommend Querious. It’s a great way to manage both local and remote databases, and it’s pretty cheap. Once you get it installed, connect to your local MySQL stuff by using localhost with the user root:

You can then create and modify all the databases you want. Your mom will be so proud.

A couple other options for a thick client database manager are Sequel Pro and Navicat for MySQL. In my opinion, the UI on these apps is inferior to that of Querious, but they may possess power that you need.

Extra Credit: Sweet Virtual Hosts

Wow, the nerd factor on this blog post is really getting high, but there’s one more thing I have to tell you about: virtual hosts. Patrick Gibson provides a handy little script and handy little instructions on how to make it so you can give unique names for the folders in your Sites directory. So if you have a family blog in there, you can create a virtual host called “family” and when you go to your browser, you just point it to http://family and it references that folder. It’s great. Check it out.

Lots of thanks to Wade and Rob for helping me learn this stuff.
Happy local server-ing!