Anatomy of Project 365
With the recent launch of my Project 365 website, I thought some people might be interested in what technology went into creating it.
Server-side
- Rackspace Cloud Servers – This was my first use of Rackspace, and I’m actually quite happy with the service. The price is very reasonable, and the customer service is some of the best I have worked with.
- Rackspace Cloud Files – While in many regards I like Amazon S3 better, I chose Cloud Files because of the free bandwidth to my server and for the deep integration with the Limelight CDN network. Each photo that is viewed from Project 365 is served through that CDN, and this ensures the fastest and most reliable experience possible.
- Debian 5.0 (Sarge) – Ubuntu is the new superstar in the Linux world, and I think it’s a great operating for a novice user looking for a stable desktop. For a production server, however, I’m a firm believer in Debian. Releases are slow and deliberate, and I can be certain that every piece of software has been tested.
- PostgreSQL – I’m not certain why so many people use MySQL. PostgreSQL has a ton more features, and its future isn’t tied to a corporation with a history of killing good products. This was my first experience with PostgreSQL, and I’m very happy with that choice so far.
- nginx – Apache is the 800-pound gorilla in the web server world, but it was simply overkill for what I needed with this site. I opted to go with the light-weight nginx, which is the only web server that Wordpress.com found to be usable for their workloads.
- Phusion Passenger – Combined with Ruby Enterprise Edition, this is simply the fastest, most memory-efficient method of running a production Ruby on Rails server. Recent support of nginx made the choice a no-brainer.
- Ruby Enterprise Edition – On average this reduces memory usage by 33%. Consider me sold.
- Rails 2.3 – I happen to like Python better than Ruby, but there is simply no competition between Django and Rails. Rails is the perfect implementation of the MVC design paradigm. When it came time to design this site, Rails was the clear choice.
Development-side
- TextMate – TextMate is by no means the perfect Ruby editor, but I use it for basically everything. Bundles are great, and it provides me with a consistent experience across any programming or markup language that I’m using.
- git – I admit that I am by no means a revision control expert. This is a crowded space, and with no prior experience I made this choice based on technical merits alone. I believe that the distributed nature of it is perfect for the chance that I have to work with another developer, and its speed is incredible.
- GitHub – I use GitHub primarily as the primary location to store my code. When I am done with my local changes, I upload them there. When it is time to load a new version of the site on a server, it pulls it from there. This also provides me with a remote backup of my code in case something happens to my laptop. It is easily worth the monthly fee.
- GitX – GitX is still early-stage software, and it lacks a lot of features. For what I’m doing, though, it’s still nice to have a native OS X program to set up my commits. I still have to dip into the command line to do any heavy lifting, though.
- capistrano – To be honest I don’t really even like capistrano. It’s extremely buggy software, and I’m considering writing a functional alternative. For the time being, though, it is what I use to deploy my code to my server.
- SQLite – It’s lightweight, public-domain, and file-based. In other words, its the perfect database to use on a development machine.
- Photoshop CS4 – Like everyone else, I use Photoshop to edit images. Right now the site design is very spartan (read: bad). In the future, I’m going to make a proper logo as well as a decent design. This site, however, was primarily designed for my usage, so this isn’t a priority.
Internals
- restful_authentication – One of the de facto authentication solutions for Rails, it provided a nice base for me to build my authentication system upon. It needs some patches for common tasks, and a lot of functionality has to be added in order to get a fully-featured authentication system.
- attachment_fu – This handles all photo uploads. It’s actually a really nice plugin that I use with very few patches. It comes with Cloud Files integration, and with only a little extra work it is near perfect.
- cloudfiles – I’ve written about my issues with this gem in the past, but despite a few annoyances it’s really solid. I’m actually quite impressed with Rackspace for taking the initiative to release this. Most companies would just release an API and leave the process of building wrappers to the community.
- image_science – RMagic would be overkill for this site. All I need is something to resize images for previews and thumbnails. image_science is perfect for this task, and it sports a small memory footprint.
- facebooker – Right now the Facebook integration is pretty minimal. Login is the main goal through Facebook Connect, but there are also places to post to Facebook (for example after uploading a new photo). JavaScript is the main way to communicate to Facebook, so I don’t actually use this plugin very much. It is used, though, so I felt that it should be included in the list.
- will_paginate – This pretty much speaks for its self. I use this on the index pages in order to only show a certain number of photos per page. This is a basic feature that should be included in Rails, but for now the only way to do it is through a plugin.