DG834G Negative Connection Time

Checking the status of a Netgear DG834G wireless router today, I saw it had a negative connection time...

Connection Time: -11230:00:-52

... which I'm sure is a very long time. But it can't be that long. The guys at Netgear must have either been seriously stingy with the storage allocated to this, or perhaps they never expected one of their routers to stay up for more than a few months!

Disconnect/Connect, and all's back to normal...

Firefox Profile for Web Work

If you're like me you often find new and exciting ways to crash your browser when developing websites. I use mostly Firefox for development, given the wealth of useful plugins available (Firebug, YSlow, HTML Validator, Tamper Data...). With Firefox, crash one page, and every window in the browser pukes: bummer. Yes, there's restore functionality after the crash, but with repeated crashes that gets really boring.

However, If you run Firefox with a special "profile" for development, a crash will only take down windows in that profile. To bring up Firefox's profile manager:

$ firefox --no-remote -P

Create a profile, call it something like "web_dev". Then to launch Firefox with this profile, call:

firefox --no-remote -P web_dev

Actually I use a bash alias in ~/.bashrc so I just have to type "firefox_web_dev":

alias firefox_web_dev='/usr/bin/firefox --no-remote -P web_dev > /dev/null 2>&1 &'

Now when you crash Firefox in the web_dev profile, your regular instance of Firefox won't be affected.
But there's more.
Each profile has its own set of add-ons, search engines, etc. So you can set up the HTML Validator add-on in your web_dev profile, and Adblock Plus in your default Firefox profile: you won't slow down your regular browsing by validating the whole web's HTML, and you won't have to deal with Adblock hiding the ads you do want to see on the sites you're working on.
Win-Win?

Colour Your Shells

You're doing some work on a database driven website...
You need to do some tests locally on real data from the production site's db...
No problem: just copy the latest db dump backup from the live server!

Copying...

Now just drop the db and reload the backup: dropdb my_precious_data; reload...

Wait, you're still logged in on the production server... which means: BAM! you just dropped the live database. Oops.

Perhaps that scenario seems far-fetched given the way you develop and deploy your site. But when working on a command line, you'll still find it helpful to know at a glance whether you're logged into your development machine or a production server. I do this by having black text on a white background for my local machine, and light text with a black background for remote machines:

Make Feedback Easy

I've been working on a Firefox add-on recently. Firefox is an "open source community-powered browser" according to their own website with "more than 5,000 Add-ons (little extras that augment Firefox to meet your unique needs)". If you're working on anything to do Firefox you'll probably end up visiting the offical mozilla developer centre at developer.mozilla.org.

This developer centre is powered by a kind of wiki, just as you might expect from a "community-powered" project. But what community?

Visiting the developer centre as a 3rd party developer, you might find a bug in the docs. You'll quickly realise you can't edit anything, all the little "Edit Page" buttons are greyed out. Fair enough, if you let anyone edit your documentation, you'll probably end up with a mess.

Website Deployment

Deploying updates to your website is nothing like a military deployment, except for the fact that a little planning and automation can help you not make a complete ass of it.

Say you have a one-server website, and a set of tested updates on your development machine you want to deploy to the production server.

When are you going to deploy the changes?
During your website's quiet time, when it has the least number of users. If you don't know when this is, find out.

Will you have a partially working site during deployment?
Hell no, that's worse than having no website. You could bring the website down during deployment and ho hum, but that has the tendency to cause users not to come back. Instead block off the relevant areas with an "undergoing upgrade" page, and stop people logging in whist you deploy.

Enterprise Pattern Syndrome

“Let’s have a dinner party!” your wife informs you. “It will be wonderful and fun and I want to invite all of our friends! This time I’ll even do the cooking! All you have to do is sort out the shopping.”

“A piece of cake” you reply. “I can manage that”.

So your wife hands you a list of ingredients and supplies to get: a joint of beef, some fresh baby carrots, new coffee coasters, that kind of thing. Some of it is open to interpretation eg ‘snacks + sauce for afters... pos salsa?’ and some of it, eg the Shaoxing Wine, you’re not sure even sure where to get it.

“Whoa! Stop right there lady!” you exclaim.

“What’s the matter honey?” she replies.

“Well, you haven’t told me where to get all this stuff. And for some of it you haven’t said how much you want. Also we don’t have an approved suppliers list drawn up yet. We can’t start without this infrastructure in place.”

“Well just go down to the shops, and if you can’t find it then give me a call back. No problem”.

“Sorry”, you reply. “But that’s not the way to do it. I need to examine all the stores first, and then draw up an approved suppliers list of stores that I deem reputable. That way, I can minimise your chances of getting faulty goods, and also provide you with pre-defined returns policies. After this is in place, you will need to specify precisely what you want, assuming it is available for the stores. But don’t worry about which store, I can abstract that for you, providing we both agree on a store-to-item mapping configuration (in XML of course!) which I can draw up and we can both share via use of the NoticeBoard pattern in the front room”

Your wife looks at you completely baffled.

“That’s the way we do it at the office honey” you say. “It works there!”

Security Through Asceticism

There's a recent story about several thousand websites revealing their source code due to version control directories being present along with the web content files. For example, if you use subversion to manage your web content, it creates .svn directories in each and every subdirectory of your project. If you do a fresh upload of your site and forget to remove these directories, or have had the not so bright idea of having your production site directly under version control so you can update it with "svn update", then you're revealing the source code to your site.

Maybe that's not a big deal. Everyone can see your HTML source anyway... But it could be a big deal if you're running a dynamic site: revealing your PHP code or your database schema can make it much easier for a malicious hacker to successfully attack your site. Either way, if you include world-readable version control directories in your web space as a matter of course, you're breaking one of cardinal security rules: "Have Nothing More Than You Need On Your Server".

If there are any files on your production server that aren't meant to be accessed: remove them. If there's software installed on your production server that you don't run and never will: uninstall it. Even if you can't think of any way the extra files or programs could compromise your server, chances are someone else can.

So, what should you do about .svn directories? You could have a look at the "svn export" command. You could use an rsync command to update your site, telling it to ignore .svn/*. Or you could use a version control system like git which only creates one .git directory at the root of your project, instead of spreading itself around all your subdirectories like a plague.