Diagnostic information
 
HTTP request failure
 
400: Bad Request
 
HTTP Transports available:
 
    1. WP_Http_Fsockopen

Apparently, I’m not the only one who has encountered this issue, but I did discover a workaround. Just change all the ampersands in your feed URL to the HTML entity equivalent. Example:

http://gdata.youtube.com/feeds/base/users/whatever/uploads?orderby=published&safeSearch=none

Becomes…

http://gdata.youtube.com/feeds/base/users/whatever/uploads?orderby=published&safeSearch=none

Some of you have been asking about the problem where snapshots get locked and can’t be deleted from NetApp volumes. Unfortunately, this appears to be related to the way the XenServer API interacts with NetApp’s DATA OnTap API. Unless someone out there can enlighten me, I don’t think there’s much we can do, other than wait for Citrix to fix their API. =(

K3b Ripped files pattern

%A/%T/%a - %n - %t

LAME command
Advice taken from Hydrogenaudio’s recommended encoder settings:

lame -V0 --tt %t --ta %a --tl %m --ty %y --tc %c --tn %n - %f

K3b external audio encoder settings for LAME
On my machine, LAME will not encode properly without these options:

• Swap Byte Order
• Write Wave Header

I like to make life easy for my successors, so whenever I write a program that needs to access files in or below its current directory, I avoid absolute paths like the plague. I find that it’s almost always better to use a relative path, so that if the program needs to be moved someday, it will continue to run with the expected behavior, regardless of where it lives on the filesystem.

The problem is that when a program is executed, all relative paths are relative to the current working directory of the user who executed it instead of the directory that the program actually lives in. To work around this, you just need to prefix your relative paths with a variable containing the absolute location of the program itself:

PHP:

$cwd = dirname(__FILE__)

Python:

cwd = os.path.abspath(sys.path[0])

Note that the above won’t work when your program is “frozen” (e.g. compiled with py2exe).

Windows Shell:

set CWD=%~dp0

First, a few tips:

• Clearly, it’s in your best interest to learn as much as you can about as many different technologies as you can get your hands on. However, don’t ever expect to know everything about anything. Definitely don’t waste your time memorizing things like command line options and function call parameters. That’s what reference manuals and Google are for. It’s infinitely more valuable to have a good understanding of concepts.
• This is a bit of a continuation of the previous point, but you need to realize that what you know off the top of your head is a lot less important than knowing where to find the answers. Read the manual, learn how to use  Google and IRC, and as frustrating as it may be, only ask for help as a last resort after you’ve done your own research and tried everything else. This will teach you how to teach yourself.
• Get in the habit of asking yourself “how would I do this if I had to do it 10000 times?” Computers are very good at performing repetitive tasks very quickly, but human beings are slow and error-prone. The sooner you learn how to leverage the computer to do your work for you, the better off you’ll be. Be lazy by eliminating as much manual work as possible. Your mantra should be “how can I automate this?”
• Never settle for “good enough.” Be a perfectionist, and strive to do everything the correct way according to best practices and/or accepted conventions. If you find that you’re doing something wildly different than everyone else, you’re probably doing it wrong, and in the real world, it will almost certainly come back to bite you or your successor(s) in the ass later. You might also end up reading about yourself on a site like The Daily WTF.
• Remember that the best solution is always the simplest and most elegant one. Avoid creating Rube Goldberg machines. Remember this quote by Antoine de Saint-Exupery: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

And now the fun stuff:

1. We’re going to start by building a network. In the unlikely event that you haven’t done so already, get yourself a broadband Internet connection and a cheap Linksys firewall/router. Make sure your ISP allows you to host a server (I strongly recommend DSL over cable for this reason alone). Contrary to popular belief, a static IP is not necessary, nor is lots of bandwidth.
2. Build your own server from scratch. It doesn’t have to be anything really expensive or powerful, but it should be dedicated (i.e. a different physical machine from your primary desktop) and capable of running 24/7 for the foreseeable future. Don’t waste your money on an expensive video card. Use that money to buy a cheap interruptible power supply and/or a tape drive instead.
3. Install Linux on your server. I don’t care what distribution you use, but you’ll find a lot more documentation for the more popular ones (I use Ubuntu server). Do the most minimal install for your distribution of choice (i.e. no optional packages). Do not install a GUI (or control panel) on your server under any circumstances.
4. Once your server is up and running, you are not allowed to reboot it unless it’s to swap out hardware or to install a new kernel. Your goal should be to have the longest uptime possible (for reference, my home server’s record is somewhere around 450 days). When something breaks, figure out what went wrong and fix it. Don’t just reboot and hope the problem will go away, because that will be a waste of an opportunity to learn something.
5. Without a GUI, you’ll need to do everything on the command line. Get familiar with Linux’s filesystem hierarchy. Learn about what files go where and why.
6. Register a domain name, but do not purchase off-site email/web hosting. From now on, you’re not going to pay anyone else for anything you’re capable of hosting yourself.
7. Make your domain resolve to your home Internet connection. If you don’t have a static IP address, get an account with a dynamic DNS provider and learn how to make this work.
8. Install Apache and start a blog. You’ll use it to document things as you learn them. Learn how to open the necessary ports in your firewall to make your website available to the whole world. Does this scare you a bit? It should. Your server is now wide open to attack. Start learning how to secure your server. Be paranoid.
9. Install SMTP, POP3 and IMAP servers, then tell everyone about your new email address. If you have other outside email accounts, forward them all to your new address and use it exclusively. Set up server-side spam filtering and learn how to defend yourself from spammers.
10. If you haven’t already, get a cheap tape drive and learn how to back up and restore your files. Then learn how to take automated nightly backups of your critical data.
11. Now that you’re your own webhost, give your friends accounts on your server and host their websites/email too (the more the better). Learn how to set quotas and secure your server on the inside so that your users can’t break it on you. Then test yourself by challenging them to break it on you.
12. Turn off the crappy DHCP server on your router and install something more powerful (e.g. ISC-DHCP).
13. Install BIND and use it in place of your ISP’s DNS servers. Learn how to edit zone files by configuring an internal DNS namespace and putting every device on your network into DNS. Don’t forget to create a reverse lookup zone. Learn how to use the dig command.
14. Combine your knowledge of DHCP and DNS to set up dynamic DNS updates.
15. Now that you know your way around a Linux box, back up your home directories and set everything back up again on a fresh install of Gentoo Linux.
16. Learn a popular web-programing language (e.g. PHP, Python, Ruby) and build your own website/blog from scratch. For bonus points, start by creating your own MVC framework.

That aught to keep you busy for a few years! And once you’re done, you’ll have more working knowledge than 99% of the people out there applying for entry-level IT jobs.

Step 1: Describe the problem

This is the easy part. Find out what the problem is and reproduce it. That 2nd part is important, because the typical user can’t always be trusted to know what they’re doing. By reproducing the problem, you can rule out user error and verify that there actually is a problem.

Step 2: Gather and analyze data

This is the part everyone likes to skip, and is the real subject of this rant. Step two requires direct observations in order to find out exactly what is happening. How you do this is very much dependent on the problem at hand, but it involves things like log and packet analysis (which may very well require a 3rd party tool not included within the base OS). In any case, do not just take a wild guess about what’s causing the problem and then proceed down the path of random experimentation. I don’t know for sure how people acquire this bad habit, but I have a strong suspicion that it comes from working in Microsoft Land, where the computers have personalities, rebooting is the inexplicable fix for everything, and a sea of GUIs gives the novice system administrator ample opportunity to click around through options he/she doesn’t understand.

Part of problem in Microsoft Land is that they love to make troubleshooting harder than it needs to be. For example, there is a severe lack of useful troubleshooting tools included within the Windows OS itself. Why are the Windows support tools, resource kit tools, and IIS diagnostic tools still separate downloads? The same question can be asked about the Sysinternals Suite (which Microsoft has owned for several years now). Why are they still shipping obsolete utilities instead of their newer replacements (e.g. nslookup, which was obsoleted by dig many, many years ago)? And lastly, why does Microsoft constantly try to hide any information that could be useful for troubleshooting? Anyone who has ever had to view the message headers on an email in Outlook knows exactly what I’m talking about here, but I digress.

Step 3: Form a hypothesis

It isn’t until you figure out what’s happening that you can address the question of why it’s happening. Step three is where you use the information you gathered in step two to determine a logical course of action. Remember that a hypothesis beginning with “maybe” or “I think” (with little or no direct evidence to back it up) is often a dead giveaway for someone who doesn’t know what the hell they’re talking about.

Step 4: Test your hypothesis

Perform your planned course of action.

Step 5: Analyze results and draw conclusions

Check to see if the issue is resolved. If not, revert your changes and go back to step three. When drawing conclusions, ask yourself how this problem occurred in the first place. Was your most recent fix permanent or just a temporary bandaid? If the fix was temporary, make sure you schedule a time to implement a permenant fix.