The Technician

Having your own domain and server is a really fun thing. You can keep a blog, store files, post photos. All good ole down-home interwebz fun you can dream up. With the advent of micro-blogging, everyone now has an audience they need to communicate with in the briefest fashion.

Short links have become the norm for sharing, but with a huge price. Short links break the interconnectedness of the Internet. Search results that depend on the count of links become incorrect. Some services try to reconnect links between domains by using some DNS trickery. But the issue remains that there is a middleman that can’t help make the connection.

Unless, of course, that middleman is the search engine. Google’s recently announced URL shortener could solve many of the problems inherent with URL shorteners. By being the middleman, Google would have all the necessary information to put the pieces back together. It’s easy enough to set up, provided you have a Google Apps account. It does not currently have an API, but here’s hoping.

I am pleased to announce that this site is now hosted on the Rackspace Cloud. It was a simple migration from MediaTemple, and has given me the level of control I want. I got to choose my OS (CentOS), versions of php and MySQL, and setup apache how I like it. I’m free of Plesk and those and the limitations therein.

The one thing I would really like to see from the Rackspace Cloud is DNS Support. My goal when migrating http://chr.ishenry.com was to move entirely off of MediaTemple. The one thing I really did like about hosting with them was that DNS was integrated directly into the service. With the Rackspace Cloud, there was no such convenience. However, a quick signup with DynDNS and a tweak to my domain registrar solved that.

Big thanks to Ryan Kearney’s video tutorial for the yum command that brought everything together.

xq94dwsy2u

A Zombie Project is any project that has been completed for a while but needs to be changed or updated in some way. After laying dormant for a while, the team that developed it may have left, or evolved into a different team, or changed their methodology entirely.

While the project was dormant, it is extremely likely, if not definite that knee-jerk reactions to bugs have caused changes that no one remembers, much less committed. So when development starts on the project sandbox, if it still exists, it is more likely than not that everything is out of date. In this case, bite the bullet. FTP the whole codebase down, and check it against the repo. Your life will probably be miserable for a bit, but at least there won’t be any horrible surprises later. Also, if there’s a sandbox, triple check it. If not, be glad there’s nothing you’ll miss in an old one.

If this project is only being opened for a short period, resist the urge to make small changes in methodology or framework. For every small change you make, you’ll want to make another, and update this, and modify that. Be extremely careful of the budget, and cost of each change, or you’re done for.

Lastly, be very, very afraid of the build to production. Even with fastidious notes, a sys admin with OCD, and Gillian the QA girl telling you how awesome you are, assume you missed something. An open tail of the error log is your best visibility into whatever has reared it’s ugly head. Your next best bet is your trusty Crisis MO.

When making changes to a large site, it’s really helpful to have tools to measure how those changes affect performance. One of my favorite tools is cacti. This is a graph of the load average of one our database servers

Database Load Average

We done good…