Today saw the final shutdown of our original sandbox development server. This PentiumIII 700MHz machine was assembled from all the best spare parts that could be found around the office at IDX almost 2 years ago. It ran Debian 3, Apache 2, PHP 5, and MySQL 5. The proftpd deamon was errored in such a way that it sometimes took 5 or more tries to log in. It’s 768 Meg of RAM meant that running anything while the machine was acquiring MLSNI data Apache would freeze up. Still the only downtime was during power outages and when we moved to a larger office.

This server saw us though all development of our app from the first <?php to today. When the power button was first pressed on this machine IDX had only 1 employee (me). We now have 5 and are about to hire a 6th. When this machine first loaded it’s kernel Google had not yet purchased YouTube and the world was still buzzing about Cheney shooting an old man in the face. Apple was celebrating its 30th birthday as this server was was getting sendmail configured. It’s been an interesting couple years.

We’ve been undergoing some pretty significant operational changes at IDX following the launch of the new search class. We had previously been working in a purely sandboxed environment. With our team small and our attention so focused on building a solid application there wasn’t a need for true versioning. Plus working on a live non-production server made our constant steams of small changes an easy implementation task. Over the past year it has become apparent that we’ve grown too large for that system.

My right-hand man Torgie¹ was been working hard for the last week or so on getting our versioning system up and running. We upgraded our sandbox from a P3 700MHz machine with 768 Meg of RAM (I still think you produce better code when you write for a slow machine) running Debian to aP4 1.8GHz machine with 2Gig of RAM running BSD. We’re also now working entirely within Subversion and have instituted a double-dot-alpha version and release schedule².

SVN also meant that we had to switch to an IDE that had good source control support including subversion. Torgie and I did a fair bit of playing with different software packages and, honestly, didn’t find a “perfect” IDE for PHP. VIM is… vim. Plus it lacks butterfly commands. Eclipse is, IMHO, overly complicated. Within 10 minutes of testing the Zend IDE it deleted all the local copies of our code. I’m sure it was user error, but it still puts you off a piece of software pretty quick when you have to worry about it nuking your code. Finally I stumbled upon the Komodo IDE that I have mentioned previously. It has it’s own set of short comings (more posts will certainly follow on this issue), but it seemed to be the most well rounded IDE we’ve found. The final votes aren’t in, but I think we’re planning on sticking with Komodo for now.

It’s been… fun. Torgie spent today writing the hooks that should mean we can make the final transition to our new version controlled sandbox. And while all this goes on I’ve been madly trying to get our AWS scripting in place while the rest of the team continues to add MLSs to our system at a rate of about 3 a week. No stress.

¹ I couldn’t decided if I should call him “Number One” or “My Girl Friday” so I used it as an excuse to make a footnote.
² New features will be single dot (3.1), Bug fixes and minor enhancements will be double dot (3.1.4) and critical fixes will be alpha (3.1.4b).

To simplify my development life I recently dumped windows at the office in favor of Kubuntu. I was sick of having tons of hacks and work arounds to allow me to develop, in windows, an application designed to work in Unix. I made the decision to go with Kubuntu (Gutzy) because I really like Debian based distributions and having played with Ubuntu in the past I know how quickly it can be set up. Our web servers all run BSD, but I’m more of a Linux type of guy when it comes to the desktop.

So far I couldn’t be happier. My IDE of choice for PHP is Komodo which has a native Linux version and works great. I have all the same versions of PHP, MySQL, Apache and SVN that are running or live server, so there are no surprises when I commit changes. The remote desktop client that installs be default with Kubuntu seems slightly faster than the windows client, so when I need to double check work in IE I can connect to our windows server and even over our slow 100Mbit LAN it seems just as fast as sitting at the windows box. The Nvidia settings manager makes running and configuring my multiple monitors easy though I miss the “To other monitor” button that I had in windows via UltraMon. The prettiness of Compiz makes up for it though.

I kept a 20gig windows partition “just in case” but I’m really thinking of dumping it and mounting that space for my home directory. If the Google sponsored wine improvements really make it possible to run photoshop CS2 with decent performance in Linux then I can’t think of much that would lead me back to windows.

After completing my work with the new search class I’ve moved onto something completely new to me. I’ve been doing some tests with Amazon Web Services to decide if S3 and EC2 would be a viable alternative to running our own image server with multiple terabytes of storage plus redundancy. So far I’m very pleased with the performance I’m seeing.

I’ve pieced together a PHP class that meets all our needs for pushing and pulling files from S3. I have all the raw functionality in place and now I’m working on response parsing, error checking, and redirection detection. There are plenty of prebuilt PHP S3 solutions out there, but I’m a bottom up type learner, so building this class was the best way for me to learn how to use S3.
After looking at the alternatives and doing some math I’ve built the class using the HTTP_Request pear package for transmitting of files over HTTP via REST. The overhead of passing authentication headers with every file still seems the be preferable to the size of a SOAP envelope. In some informal benchmarking I’ve found I can reliably transfer small files at between 50 and 60kbps. This is ample for the small number of file we’ll be uploading directly from our web server directly to S3. Most of our uploading will be done via an EC2 instance which is much faster.

I also found a firefox extension called S3Fox that allows me to interact with S3 as if it were an FTP server. This will allow me to easily keep an eye on things as is sometimes necessary when automated processes go awry. It’s also been helpful in some early testing to know that my code runs at least as efficiently (if not slightly more so) when uploading objects as this extension does.

The next part of the plan was setting up an EC2 server. I instanced my first server this morning and made enough changes to the base apache-mysql image so that I’ll be able to start installing code next week. The process of instancing an EC2 server is a little conveluted at first, but as soon as all the tools are in place maintenance is a breeze. It also very easy to export server images once you get things set up the way you want them. That will allow us to have all our code and settings in place as soon as the instance launches. I ran the same informal small file benchmark from the EC2 server that I mentioned above and I got well over 200kbps of upload speed. Larger files will also run faster due to the per file header and response overhead.

All-in-all I’m very satisfied with the way things are working out. Hopefully it won’t take me too many more code hours to get a bullet proof system in place to reliably use AWS as our image solution. Though in terms of days there may be some time before I can activly start moving existing images over as next week we’re going to be bringing a new versioning and ticketing system online on our sandbox.