For several years now, I've been using Thawte's free personal email certificates to sign and encrypt my email. However, when I went to renew my certificates today, I found myself in disbelief that Thawte has discontinued this service, offering instead a free one-year VeriSign certificate that renews for $19.95.
Despite our strong desire to continue providing the Thawte Personal E-mail Certificate and Web of Trust services, the ever-expanding standards and technology requirements will outpace our ability to maintain these services at the high level of quality we require. As a result, Thawte Personal E-Mail Certificates and the Web of Trust will be discontinued on November 16, 2009 and will no longer be available after that date.
While disappointing that this once free service has been EOLed, I'm also relieved to not have to use their system again. Thawte's certificate generation tool was never very usable, and often required jumping through Firefox-shaped hoops to get the certificates installed on a Mac. Even then, the basic certificates contained only your email address, and not your name. If you wanted your name on the certificate, you had to join their Web of Trust, which meant meeting up with other members in real life to have them vouch for your name. This required multiple in-person meetings until enough points had been accumulated for Thawte to be able to confirm that you were who you said you were. It was a nice assurance in theory, but I was never able to track down anyone locally who was actually willing to do this.
But what to do about an alternative? While signed emails are nice, I'm not sure that I could justify the $20/year fee associated with a paid certificate from VeriSign. I poked around a bit and found a company called Comodo offers a free secure email certificate, and their signing process is a huge improvement over Thawte's. Just fill out a single form with a handful of fields, then look for an email with a link that will install the certificate right into your Keychain if you using Mac OS X. Mail.app will pick up on these certificates automatically, and start signing your emails by default. And, bonus, they even let you put your own name on it.
Earlier this year, there was an ORUG meeting at the Voxeo offices in downtown Orlando. They sponsored the meeting that night, and in turn gave us a demonstration of a cloud-based telephone platform called Tropo. Among other things, it allows you write scripts to answer phone calls in languages Groovy, JavaScript, PHP, Python, or Ruby. This is cool technology, and something that I knew I wanted to play around with after seeing the demos.
The first idea to pop into my head was to build an interface for Twitter that would let you hear your latest tweets by calling in with your phone. It didn't take more than a few hours that night to throw together what would become Tweeter Phone. This was in the days before OAuth, so updating it to use to not require people to enter their Twitter password was the first big feature request I received.
Initially, it used the same layout as this site, but I always wanted it to have its own layout: something light-hearted and appropriate given the casual nature of its usage, toy-like, and immediately obvious what it was and how it should be used. I'm no designer, but I like to pretend now and then, and this particular exercise also gave me a chance to play around with font embedding. The fonts I chose, Folk and Playtime with Hot Toddies, are responsible for most of the site's tone, and lent direction to the rest of the design.
I also took the opportunity to rewrite the site with Sinatra and DataMapper. It was a small site to begin with, and I wanted to further reduce its complexity by stripping it down to the bare minimum. For instance, I forewent the feedback form for a simple link to Twitter with the text area already populated with @tweeterphone.
See the brand-new Tweeter Phone, and, to stay in the loop about future updates, be sure to follow us on Twitter, too.
David Rogers asked me a while back to give a presentation to the Orlando PHP users group on Git, including some background on version control in general. The presentation I gave at the meeting last Thursday, Git Acquainted, took a brief look at the history and basics of version control, and then demonstrated enough of the basics of Git and GitHub to get someone new to version control up to speed.
Also, I just saw that Chris Wanstrath has released a new Ruby script called hub that extends the git command with GitHub-specific extensions. This makes tasks like checking out GitHub repositories and adding remotes for other GitHub users trivial. Plus, "because hub only adds functionality, it's safe to alias to git in your shell."
If you had previously installed PostgreSQL from source, you might want to recompile after upgrading to Mac OS X 10.6 (Snow Leopard) to gain the performance advantage of having 64-bit binaries. This process is straightforward with one exception: you must dump all of your data before upgrading, and then reload it after the 64-bit version has been installed.
Restoring the postgres User
At least for me, the Snow Leopard upgrade removed the postgres user from my system, but left the postgres group in place. See the PostgreSQL installation guide for Leopard for instructions on how to recreate this user.
Backup First
It's always a good idea to do regular backups, and doubly so before performing any sort of software upgrade. In this case however, the backup is a prerequisite to the upgrade process. Luckily, PostgreSQL's included tools make it easy.
pg_dumpall -U postgres > ~/32-bit-dump.sql
This will prompt for the postgres password for each table in your database, but in the end you'll have a single SQL script to restore all of your data.
After the backup is complete, you should shutdown the running daemon.
sudo launchctl unload /Library/LaunchDaemons/org.postgresql.postmaster.plist
Recompile the Binaries
The default compile target in Snow Leopard is x86_64, so recompiling is as simple as following the standard source compilation process. If you've kept your source tree from the original installation, you'll likely want to run make clean first to ensure all of the old 32-bit binaries are cleared out.
./configure --enable-thread-safety --with-bonjour
make
sudo make install
Rebuild the Data Files
Next, we'll have to remove and reinitialize the data files since the data format in PostgreSQL isn't architecture independent. This will wipe all of the data in your database, so please make sure you've followed the backup instructions above before continuing.
cd /usr/local/pgsql
sudo mv data /tmp
sudo -u postgres ./initdb -D /usr/local/pgsql/data -U postgres -W -A md5
This will prompt you for the new superuser password; just enter your old one to keep it the same. Now the old data can be loaded in again.
psql -U postgres -f ~/32-bit-dump.sql
Updating the Ruby Gem
If you use the postgres gem, you'll need to recompile it against the new shared libraries.
sudo env ARCHFLAGS="-arch x86_64" gem pristine postgres
Reverting to 32-bit Binaries
If you happened to recompile before backing up, you'll need to revert back to the 32-bit version before you'll be able to restart the database and make a dump. Just follow the steps above for recompiling, but add the appropriate flag to specify the 32-bit target architecture.
CFLAGS="-arch i386" ./configure --enable-thread-safety --with-bonjour
Now you can restart the daemon and follow the instructions from the beginning of this guide.
I'm excited to announce that I've been asked to be a part of a new venture called Envy Labs. It's a full-service development and media shop backed by Gregg Pollack of Rails Envy fame. We have a great team in place, and with the launch of the site today, we've also published a new blog called Lab Notes with a some great first posts:
Keep an eye out for more good stuff coming soon.