Monthly Archive for July, 2008

Dare to Dream

For a couple of years, I was a volunteer for the LiveJournal Support department. I was there long enough to rise to the level of a Support Administrator. I was initially drawn to it for a number of reasons. While much of it was boredom, I chose LiveJournal Support in particular because of the open-source nature of the project, the high ‘webmoral’ standards of the people in the driver’s seat like Brad Fitzpatrick, and the great community feeling of the people who did it. It was users helping users.

Over the couple years that I was involved with the project, lots of things ended up changing. Danga (LiveJournal’s parent company) got bought up by SixApart in January of 2005. 6A was a much larger company, and initially we were all quite happy that more development time and money might be provided to the project. However, this was not the case, and LiveJournal was sold once again to Russian-based SUP (pronounced “soup”).

Now don’t get me wrong — the time with SixApart wasn’t really all that bad. A lot of improvements were made to the service. However there were also some controversial changes (e.g. introduction of site ads). I can’t go into any detail (due to the NDA’s I have with Danga/SixApart), but there were things happening in the background that were out of control of the people who managed LiveJournal day-to-day (e.g. changing company circumstances, directives from upper management, etc..). In any case, the site continued to change under the direction of SUP, most recently with the removal of the Basic/Free account level (leaving only the paid or ad-supported account levels), and now proposed restoration.

Now I didn’t leave because of these reasons. I left because I no longer had interest in devoting time to the project. Now this is partially due to changes in my own life, but I think that deep down part of me was feeling a bit alienated. I lost my passion for what I was doing and had no motivation as a volunteer to keep helping.

The ideals of the original site are all but gone.

The site has the same name, but deep down at it’s core, it’s not the same site. It’s like waking up and realizing that your spouse of some years is a completely different person. Okay, well not quite as dramatic, and less worry about STDs, but you get the picture. Don’t get me wrong, I’m not taking a swipe at SixApart or SUP — there are some very smart people who have and/or still do work for them. I’ve never operated that large a company and am not qualified in the slightest to comment on their operations, beyond being a user who wonders if his journal, as he knows it, is going to be there tomorrow.

Now this is where an intrepid group of people comes in. A group of people — some former staff, some previous volunteers, all just regular LJ users — dared to really dream of where a site LiveJournal could be if it was completely driven by the community and had less overhead of a corporation. And so, Dreamwidth was born.

Now this is no small undertaking from both a technical and social standpoint. This group not only has to work on getting their new fork of the open source LiveJournal-codebase up to modern spec, but they are also looking to start a hosted community around this software, with more open and transparent community-based management. They are however making great leaps and strides.

It really gives me that warm and fuzzy feeling inside that a community can grow so passionate about what really is their online “home” that they can pull something like this off. And I have every bit of faith that they will. Good on you, Dreamwidth team.

And we’ll see.. maybe I might try and see how far my PHP knowledge translates over to Perl…

Paperwork

Well, I’ve earned another piece of paper to hang on the wall. I’m officially a Cisco Certified Network Associate. I’m quite thrilled about this one, as it’s the first one specific to the networking field (and inherently, my current job!). I’m now all smart and stuff. Finally, someone other than me is recognizing it. ;)

My next project is going to be finishing off my MCSE. I’m not really using this knowledge (especially considering I haven’t used Windows in over 6 months), but I’m only 2 exams (in a 7 exam series) away from getting it, so I might as well finish it off. It’s still a really beneficial piece of paper to have, and a safety net is always good.

mod_rewrite and caching servers

To better learn about the different PEER1 products that I support, I’ve recently been playing around with the PEER1 Content Delivery Network. The most common CDN set up is to point it at the same webserver you run your main site off of, and then you link back any images or static content back to the caching name instead of the primary name. For example, if your site was www.example.com and your CDN was set up at cache1.example.com, you would point both domains at the same server and then link all your images through the cache1.example.com, while all your text pages and such would pull straight from your webserver. Now, while you would also be able to pull everything including the webpages through the cachers, the issue arises with freshness of the page. This holds especially true when you’re working with dynamic PHP content.

I ended up running into a bit of an issue. I wanted to maximize the amount of content I’m serving through the CDN, however my website is based off of WordPress. I had two options.. I could rewrite the entire style I’m using to staticly grab the files from the caching server, as opposed to the regular webserver, or I could find a way to dynamically redirect all images to come from the caching server as opposed to the regular webserver. I ended up finding a way to do through the Apache mod_rewrite module.

First, I went into the config file for my main toph.ca server and stuck in this line of code:
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^(.*)(jpeg|jpg|gif|bmp|png|mp3)$ http://cache.toph.ca$0 [NC,L]
</IfModule>

Then I hopped over and into the config for the caching server (they are running on the same IP using Name-based VirtualHosts) and stuck this in:
<files ~ "^(.*)(htm|html|php|js|HTM|HTML|PHP|JS)$">
  Order allow,deny
  Deny from all
  Satisfy All
</files>

Now this does two things. First off, this causes all requests to www.toph.ca for media files to be automatically be redirected to cache.toph.ca. It’s a simple catch all, and it works! This doesn’t entirely reduce the load on the server as the requests still have to hit my Apache server to get the redirect, but my server doesn’t actually have to serve the files unless the cacher doesn’t have them. The second snippet of code on the cacher prevents the server from serving the actual data html or php files off the server. I don’t want that caching server serving web pages to users, or getting them indexed in Google.

So there you have it. A quick and dirty way to force all your media content over to a CDN caching service (or any alternative webserver for that matter), and to prevent that server from serving your actual page files.

Good To Go

Well the new design is up and good to go. I’m quite happy with it, actually. I’ve also set up a projects area that I can start posting the little web projects I work on.

And because I’ve always wanted to:
Monkeys
The heavily armed monkeys guarding the servers currently report no site-wide problems.

(1)