Nearly three hours into the class, we’re still on introductory slides and there’s confusion among attendees about how Elastic Block Storage works.  Also, the network here has slowed to a crawl so even the presenter’s online examples are being impacted.  Usually, at conferences, I forgive the inevitable network issues that arise when a roomful of developers go online at once.  But when you charge for a class focused on Web-based technologies, I think it’s a requirement to be prepared to handle the traffic.

Still, I’m hoping things pick up after lunch and that we actually into the examples.  The goal is to get under the hood of a video sharing application that runs off EC2, S3, and other Amazon Web services. Fingers crossed.

Update: We got a little further after lunch, and finally got a little more hands-on with some of the tools available for administering EC2 and S3.  So we practiced launching Linux and Windows server instances, transferred files to S3 buckets, and mounted EBS volumes.

But we were clearly short on time and had to skip most of the code examples.  In particular, we never got to the video sharing application — which was the entire reason I signed up.  While administering AWS is a necessary step in developing and deploying applications on Amazon’s infrastructure, it’s hard to justify spending $175 and the related costs of an entire day away from the office only to come back with no real insight into the architecture of an AWS application.  The session was touted as a “Developer Bootcamp” after all.

What could the presenters have done differently?  Four things:

1. Skip the 45-minute-long “team building” exercise at the beginning of the day.  For a one-day session during which there is no other group work, there’s no need to “team build.”  If you want to encourage people to meet others, a 10-minute round-robin of people introducing themselves and saying why they are attending would suffice.
2. Don’t switch the software requirements once attendees arrive (as our presenter did.)  We wasted valuable time as everyone tried to download the new code samples and consequently brought the entire network to a halt.  People should arrive at the session with all the necessary software installed and ready to go.   If people need help with configuring the software, maybe ask them to arrive early during the breakfast portion of the day?
3. Ensure that the network can handle the traffic.
4. Don’t spend so much session time answering tangential questions.  The goal of the day is to provide a developer-level look at how one can build an application on AWS.  Attendees who have specific questions about AWS or need clarification on things that aren’t core to the session should be encouraged to re-ask their questions at lunch.

Hopefully the presenters will improve in subsequent bootcamps.  Based on the peformance at this one, however, I can’t recommend it to other developers.

Update 2: Amazon has refunded the $175 I paid to attend the class.

I had put off migrating for months, worried that it would cause even more problems, or that I would lose posts or comments in the process. Fortunately, no such thing happened. The migration went very smoothly and took about two hours. There were only a couple little speed bumps along the way, but hopefully in outlining them here, others will be able to get past them a little faster.

Here are the steps I took:

1. Preparation. Checked my site analytics to see which pages on my blog were being accessed the most by visitors. This part was useful for setting up the URL redirection in step 6. If you don’t have any analytics on your site’s traffic, you may want to set up a Clicky or Google Analytics account and let it collect data for a week or two first.

2. Export. Exported my blog posts and comments from Movable Type. Unfortunately, the migration guide provided online by WordPress is admittedly “obsolete,” according to a note at the top of the page. Keep it nearby, but note the following change:

In MT 4, the export tool can be found by logging in and clicking on the System Overview menu in the upper left of the page and selecting the Tools option. On the page that comes up, choose the Export option from the links in the left column. Then on the next page, choose the Select Blog link. It should be straightforward from there. I saved my exported blog as a text file on my local drive.

3. Converting (or not). The WordPress guide tells you to check to see if your MT blog posts were encoded with something other than UTF8 and provides some options for converting your exported file to UTF8 (WP’s default encoding) if you need to. This is to ensure that special characters, like curly quotes and letters with accents, or characters in other languages, don’t get mangled when you import into WP.

Since the quotes in my export file seemed to be standard straight quotes, and since I didn’t recall using special characters in my posts at all, I didn’t bother — and haven’t noticed any problems as a result. If you’re not sure, you may want to run your export file through one of the recommended conversion utilities just to be safe.

4. Backup. I simply tarred up all the files from the directory where my blog lives so that I could recover the Movable Type blog in case something went wrong with the WordPress installation.

tar cvzf backup.tar.gz public_html

5. Database Creation. I created a new MySQL database and user for that database via my hosting provider’s account control center. Since this database is separate from the one where my Movable Type blog is stored, I didn’t bother to backup the MT database — but you may want to anyway, just to be safe.

6. Temporary Redirection. I added some mod_rewrite rules to the .htaccess file in my blog’s directory to ensure that visitors to my site would see an appropriate message (rather than a mess) while I was setting up WordPress. In a nutshell, my mod_rewrite rules looked for attempts to access any of the popular pages noted in Step 1 and instead redirected visitors to an index.html file containing my “please wait, we’ll be back soon” message.

The WP migration guide has some info on how to do this. (Note that this method only works if your hosting provider is set up to let you modify your .htaccess file and has mod_rewrite installed.) Note that you want to use index.html instead of index.php for your “please wait” message because the WordPress installation itself contain an index.php file.

7. WordPress Installation. I unzipped the WordPress files into my blog directory. I also made this directory world writeable for the time being. I changed it back later, after installation was done, but I find it’s easier to let WordPress 2.6 write settings to the configuration file and even update the .htaccess file on its own — and to do that it needs write access.

8. Import. The WordPress guide tells you to edit a file called import-mt.php in the directory wp-admin/import/. However, the import tool in WP 2.6 has a standard Browse button that lets you directly select and upload the exported MT file from your local drive. That route seemed simpler; I took it; it worked.

9. Configure. I selected a theme for my site, set up the sidebar, turned on smart URLs, and so on.

10. Final Redirection. Finally, I modified my .htaccess file again to now redirect people who might visit old Movable Type URLs to their new WordPress equivalents.

I also deleted the index.html file that had my “please wait” message. You can rename the file if you want to keep it, but leaving it named index.html would be a problem because most Web servers will continue to serve up index.html instead of index.php if the former exists.

And that was it — I’ve now got a WordPress site, not a Movable Type one.  Not too bad, right?

Not so fast. I’ve been putting both services through their paces over the past few weeks and it’s clear that, in many cases, Clicky is far better. In fact, I must admit that I’ve become addicted to Clicky.

How does an upstart fee-driven service beat a “give it away for free” giant like Google, you ask? Here’s how: First, Clicky provides a much more usable interface for accessing your analytics. That’s a surprise, given that Google is known for its usually sparse and simple interfaces. Yet, somehow Google managed to completely clutter Google Analytics. Finding meaningful reports means navigating your way through all the nested sidebar links, and the graph at the top of each pages is often redundant. And if you’re not using Google’s AdSense for advertising, parts of the interface are simply useless and get in the way.

Clicky on the other hand has a very clean dashboard and simple tab-based navigation that lets you quickly access important stats about your sites’ visitors and what actions they took as a result of your content. A “Spy” feature lets you drill down on actions taken by a single IP address (though the feature could possible use a less creepy name.) And unlike Google Analytics, Clicky automatically tracks user downloads and clicks on outgoing links.

But what makes Clicky so addictive is that it offers real time analytics, as opposed to Google’s 24-hour delay. So you can pull up Clicky at any time and see how many people have already visited your site that day, roughly how many are on your site at that given moment, and how they’re reacting to content you published that morning. Try it, and you’ll likely find yourself checking Clicky several times a day. No more waiting around for Google or your logfile parser to crunch numbers and produce a final report.

To be fair, Google Analytics does have some features Clicky doesn’t — in particular, “goals”, which is the ability to track traffic through a particular “funnel”, or set of pages. (A note on Clicky’s site says those are in the works.) Likewise, Google Analytics’s integration with AdSense makes it a popular choice for people using AdSense. And finally, Clicky currently does not offer tracking for sites with more than 100,000 pageviews per day. (We imagine that will change as the company grows.) But if you don’t need those things at the moment and are looking for a simple, intuitive way to track and analyze your site’s traffic, Clicky is by far the better choice.