Software development relies on source control management software such as CVS, Subversion, SourceSafe, Bitkeeper, Mercurial, Git and the like to track and manage the changes in the source code over time. As a project progresses, developers come and go, contractors come and go and the activity on a given project ebs and flows as required.
Attempting to visualise who, what and how much of a project is changing is quite complex as there are so many variables – however Michael Ogawa has built a project named code_swarm which does just that. Instead of providing tabular or static images to help visualise a projects changes, he has managed to animate it into something quite spectacular.
Following are five different code swarm visualisations of popular open source projects:
The amazing thing that a visualisation such as code_swarm provides, is to show just how many people actively participate in a given open source project, how much each of them participates and what sort of tasks they are normally performing on that project. As an example, comparing the number of different people in SQLAlchemy compared to Django isn’t a competition – Django is ahead by a mile, though compared to Apache, the others seem insignificant.
I recently set up a subdomain within a CPanel hosting account and ran into a strange problem.
After the subdomain was built, DNS propogated, FTP access and a database set up – I uploaded the latest version of the ever propular WordPress blogging software. As the installation instructions suggested, about two minutes later WordPress was up and running. Unfortunately the image overlays for the TinyMCE rich text editor were not displaying correctly; the buttons were present but the overlay that depicts a capital B for bold or an I for italics were not showing.
Knocking off the simplest things first:
- CTRL+R and CTRL+F5 to force the browser to reload all content
- Cleared browser cache
- Uploaded the wp-includes folder again, in case any of the images failed to upload successfully
- Checked that I could view the images in question manually in the browser by typing in the URL, which worked
at this point I was beginning to draw a bit of a blank as to what it might have been.
As is often the case, I left the problem alone for a little while and the solution popped into my head. To enable the friendly URL’s within WordPress, I needed to either make the .htaccess file writable or upload one with the appropriate configuration in it. As a matter of simplicity, I copied the .htaccess file from the main WordPress installation on the site and dropped it into the subdomain installation. Copy and paste, the bain of all evil.
Back in May 2006, people from MySpace were hotlinking images from my site. The cost of popularity from my anonymous MySpace friends was pushing my web hosting account well over its monthly data limits and I was forced to block their access using some simple rules in my .htaccess file.
Since I copy and pasted my .htaccess file into the subdomain (which resides in a folder under the primary account) – the settings in the parent .htaccess file were inheriting into the subdomain account. The result was that any requests from the subdomain that didn’t meet the hotlinking requirements were being blocked by Apache and mod_rewrite.
The solution of course was straight foward, remove the restrictions in the .htaccess file that I had uploaded into the subdomain and suddenly the images from the WordPress admin and TinyMCE started showing up as you’d expect.
A work collegue of mine would term this a junior error.
Rich Skrenta wrote an article recently about ranking web 2.0 sites by server performance, in which he talks about server response time and latency and how it impacts a site.
To see how everything stacked up, Rich decided that he’d profile over 500 of the top web 2.0 sites and throw in a healthy bunch of familiar faces as a yard stick. Some of the more familiar sites which were profiled were:
The average response times of the sites profiled varies wildly, ranging from a blazingly fast 6 milliseconds all the way up to a pathetic 15 seconds. It seems that for every 100 web sites you go down the list – it increases the average response time by approximately 75 milliseconds until you get to the outriders which skew the results.
Rich conveniently includes the web server used for the site if it was available, which as you’d expect features Apache and IIS heavily. What I found particularly interesting though, was to see where all of the super cool Ruby On Rails web sites sit within the list. You’ll notice that the programming language or platform isn’t specified within the list, so you’re probably wondering how I joined the dots – well it was the Mongrel web server which many Ruby On Rails web sites use.
Scanning down the list of web 2.0 sites, you might have noticed how many sites are running Mongrel:
- 1 – 100, three sites
- 101 – 200, two sites
- 201 – 300, six sites
- 301 – 400, four sites
- 401 – 500, seven sites
- 500+, two sites
The web 2.0 space has been dominated by people building out the next cool thing using Ruby On Rails, as it was the flavour of the month. Given that there are so few sites running Mongrel as a web site, either Rich happened to pick over 500 sites which generally don’t use Ruby On Rails or combining it with Mongrel isn’t the preferred mechanism anymore.
Everything else aside, the list does point out one really really significant thing; it doesn’t matter what web server or programming language your site or product is built in, poor design and architecture will lead to poor performance in nearly every instance. Apache delivering the fastest and slowest content within the list is evidence of this fact.