There are so many adages that apply just as well to computers and software as anywhere else in life: be prepared! An ounce of prevention is.... The wise ones will use prevention to their advantage.

For example, if you run a hosting server, and a users' domain name is about to expire, would you rather:

1. Send a short email or make a phone call to check it will be renewed by them? Or,
2. Wait until the weekend, the web site may or may not go down. If it goes down, you may be scrambling to try and fix it.

You can think of it in terms of a game of chance. Let's say sending the reminder will take 10% of the time and headache a downtime causes. 50% of the time, the domain name doesn't get renewed, and the downtime is caused. Then that ounce of prevention wins.

It's not magic to keep computers running and keep bugs to a minimum, though to some it seems like the "black arts". Developers and IT professionals experience  much they wish never to repeat again. The good ones will learn from their experiences, and if there's a known cause, next time that situation appears they prevent the bad experience from happening again.

As the years go by, this experience and knowledge starts to gel into some kind of wisdom. Wisdom is not just about fixing all the problems you've seen before , but is more like a "gut feeling" about what is a good choice and what is a not so good choice, and what you should or shouldn't do.

A couple years ago I was discussing this with a someone. Well, I was probably just blathering on about how I had fixed something that I noticed was wrong in some software, but this error was not my responsibility. Funny enough, she has done the same thing before, and for the same reason. We didn't fix the error primarily because we care about the customer. We fixed the errors because when it goes disastrously wrong, we will have to fix it, and it will be far more time consuming and frustrating to fix it than to ensure it never happens in the first place.

In software development, this wisdom works in an ongoing basis. We anticipate how the application will evolve over time. Perhaps we'll add a field in a database table for the date a record was created, because there's a good chance we may need it in the future. I'm sure there are hundreds of ways wisdom allows software and computers to run more smoothly. Unfortunately wisdom cannot be taught, so to gain more wisdom always be one the lookout for ways to anticipate disaster (and prevent it).

As a follow-up to my earlier post, recover a FileZilla password online, it only applies to version 2 of FileZilla. FileZilla 3 now does not obsfucate the passwords you save in the software, and relies on the operating system security to protect the plain text passwords (there's a scary thought).

At the time, I didn't quickly find an online form that decrypted a password nice and quickly, though since then I found at least one online form implemented in JavaScript. I have also found other versions of the decryptor function ported to PHP, so I'm adding mine below. It's a complete rewrite of the function in FileZilla. I think it's more staightforward than other solutions, but maybe that's just because I'm familiar with it because... I wrote it. I'll let you, the reader, be the judge of how readable it is. If you get a reason to use it somewhere, let me know.

function filezillaDecrypt ($password) {
  $key = "FILEZILLA1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ";
  $keyArray = str_split($key, 1);
  $clearText = '';

  // Remove everything but digits from the password
  $password = preg_replace('/\D/', '', $password);
  // Only continue if a password was supplied
  if($password != '')
  {
    // Split the password into groups of three characters
    $passwordArray = str_split($password, 3);
    $passwordLength = count($passwordArray);
    $keyLength =  count($keyArray);

    $i = 0;
    // The fun decryption happens below, using bitwise operator
    foreach($passwordArray as $char)
    {
      $keyIndex = ($passwordLength+$i)%$keyLength;
      $clearText .= chr($char ^ ord($keyArray[$keyIndex]));
      $i++;
    }
  }
  return $clearText;
}

Working as a professional software developer, you will end up with some "legacy" projects. One could call them inherited software; another developer created it, they've moved on, and now you've inherited it.

Sometimes it may be stable and built on sound principles. More often than you'd like, they are buggy and poorly designed, and your challenge as the inheritor is to just keep it running. Starting over from scratch isn't possible, so manage with what you've been given.

This morning, a recent inherited software project finally showed signs of improving. How did it communicate this to me? Instead of generating an average of ten errors overnight during a batch upload, it generated 106 errors. Some people may think more errors is a bad thing, but I do not see it that way. It is a sign that through the small changes I've made to the software - precision pokes and prods - has finally dusted the cobwebs.

It's a little like a house that looks presentable at first, but when you look more closely you find the floor looks clean because the dirt was swept under the rugs, rooms look tidy because all the junk is crammed into the closets, and the paint on the walls hide the mouldering structure. Until you see the flood of error messages, you haven't scratched the surface of the reconstruction.

Though Scott Hanselman, in IE6 Warning - Stop Living In The Past - Get off of IE6, and others would like to see users upgrade to a newer version of Internet Explorer, it may take a long time to happen with some users.

This Government agency - to remain nameless - offers no incentive to upgrade according to this pop-up warning in which requires at least Internet Explorer version 4.0:

How they continue to keep their application compatible with a 12 year old browser I do not know, but they must be geniuses!

The elegance of code is still important, for those of us who read and write code. If you use WYSIWYG editors or a code generating IDE then your code will never be elegant, but I digress.

The problem I wanted to solve today was to change the case of strings. For example, to change 'HELLO WORLD' to 'Hello World'. My challenge is to see whether I can do it with MySQL and just the built-in string functions. If it's not possible, it's no matter. I can fall back on a simple PHP script to do this one-time conversion very easily. This is because I've already written code in PHP to do this in the application for all new records that are created, and I just want to change the existing data stored in the table.

Googling a possible MySQL solution, I came across an article on Experts Exchange for the exact same problem, and they also agreed PHP is a better option than using just SQL. What surprised me on reading it was how inelegant the suggested solution was. Let me illustrate:

Their solution:

$field = strtolower($field);
$array=explode(" ",$field);
for ($i=0;$i<count($array);$i++)
{
  substr($array[$i],0,1) = strtoupper(substr($array[$i],0,1));
}
$field = implode(" ",$array);

My solution:

$field = ucwords(strtolower($field));

Which would you rather write? And more importantly, which would you rather read if you had to read someone else's code? Now my solution does have one important difference: I reviewed the PHP manual to see if there was a built-in function that capitalizes the first letter of each word. In simple terms it satisfies the DRY principle, code reuse and using as little code as possible. Sometimes all it takes is a little time and thought to create something so much more beautiful, elegant and readable - time well spent.

I bet there are still developers out there who write software where the security, and even the business logic, is dependent on the user having JavaScript enabled in the users' browser. One may as well just leave home in the morning, give your keys to the first person you see, and hope they don't enter and steal your furniture. I don't personally know any of these developers of course (or maybe I wouldn't admit to knowing them), for if I did know them I'd berate them until they stop doing it.

What I do know all too well is the software they write, and I have to fix it. Perhaps you feel as I do; fixing other people's errors as a result of their poor judgment is one of the great torments of human existence. "You mean, someone else screwed up, and now it's my problem?".

We'll be finding and fixing software made in the past for many years to come. Unfortunately, our dependence on JavaScript is not going to stop. In fact, we're probably setting ourselves up with even greater potential for error with fancy jQuery and Prototype libraries in the hands of the ignorant. I emplore you, developer, to use anything you like to enhance the user interface, but do not rely on JavaScript provide important business logic. Web sites may not function correctly in the future without JavaScript, but ensure the data is protected when it is disabled.

FTP client programs invariably have the option to save username and passwords for accounts you enter into them. For many years I used WS_FTP for my file transfer needs. Now I use FileZilla, and it's an excellent program.

Once and a while, you need to give someone the password for an account. Your FileZilla installation knows how to connect, but you don't know the original password. Either an XML file, or the registry, is where FileZilla stores all those passwords. But they are stored encrypted. Well, very weakly encrypted. It is very easy to decrypt the passwords because each FileZilla program uses the same key.

I did a search for a method to decrypt the passwords. Usually I can find an online method to decrypt, such as an MD5 hash cracking tool, etc. I found two things: The first, a shareware desktop program (which I did not try). Installing a piece of software is really not convenient in comparison to an online form.

The second thing I found, an article about the security vulnerability of weak password encryption (found here: http://www.securiteam.com/windowsntfocus/5IP0A2KGVW.html, with information provided by Adrian Pastor).The code snippet from the open source application is conveniently included on that page.

Anyone with some basic programming skills and a bit of time could figure out how the password decryption works. Even I can do it, and with PHP no less. In less than 20 lines of code, I wrote the password decryptor. I added some web form fields to make it easy to use.

You can try it below. Just open the XML file on your computer (typically at C:\Program Files\FileZilla\FileZilla.xml) and copy the "Pass" value for one of your saved accounts (it's all numeric). For example, the encrypted password of '046044063056' decrypts as 'test'.

Has this skipped a human editor? Or, perhaps this formatting was intentional....

I'm ready to learn JavaScript again.

The last time I seriously developed anything using it was 1997, creating drag-and-drop games. It was a time when very little was standardized across browsers or HTML implementations. Anyone reading this who attempted to develop drag-and-drop in the web browser 11 years ago can empathize with the intense effort to debug and make the functions cross browser compatible.

Some years later, as web browser software progressed, the games no longer functioned; optimizing to use Netscape 4 is not advantageous when Netscape 4 becomes obsolete. As JavaScript progressed, I turned a blind eye and concentrated on server side technologies that were more stable and controllable.

Today, in 2008, nothing would work if you turned off your JavaScript. Users are not put off by a web site that requires JavaScript to function. Many developers don't care if JavaScript is turned off either because, well, they keep JavaScript enabled while they build. There will undoubtedly be a growing wave of software vulnerabilities and inconsistencies because web based software was dependent on its JavaScript client-side environment. That's a whole 'nother topic.

Why should I learn JavaScript now? Browser compatibility and tools now available to developers is impressive. In comparison to the old days, JavaScript not breaking and actually working is enough to impress me. AJAX is the "killer app" for JavaScript, and is the basis for the web browser becoming the new de facto software platform. But I also like the visual effects that can be achieved without using Flash and ActiveX. Provided JavaScript does not disrupt the stability, security and accessibility of a web page, it is worth the effort to enhance the experience of using web applications.

Sometimes the biggest step is just to get started. If you have trouble getting something started, try to do the absolute smallest step that gets you in the right direction. Lao-tzu was right, "A journey of a thousand miles begins with a single step". In taking the first step, it makes the second easier than if you had not begun.

The thought of opening Microsoft Word gives me feelings of trepidation, no doubt a result of countless battles with text styles, tab indents, and under a tight deadline. In fact, I'm not yet comfortable with the WordPress blog interface for starting a blog post; the draft of this post was typed in TextPad.

Everything can begin with a text file. It is counterproductive to the formation and notation of a new idea than to be annoyed everytime to type a new paragraph, the font type changes, or the software decides that typing a hyphen is a reason to insert a bulleted list automatically. Write first, format later.

Many successful software programs rely on simple text files for their settings and configuration, including all the components used in LAMP architecture. Sometimes, the complexity you require will not exceed a simple text file.