What an adventure. I can't remember a more stressful Christmas. But I'll spare you the details and get right to the computer stuff (unless you also read my Haphazard Musings blog, in which case I will expound on the details there at some point).

The first live test of the UPS (uninterruptable power supply for those not in the know) took place on Christmas Day (December 25 for those who are completely out of the loop). The short story is, I was working on a mock prototype - which is really a real prototype, but for a fake project - to present in a prospective job interview as an example of my work. I worked on this thing for three solid days and experienced probably the worst stress of my life (certainly evoking some very distraught emotional responses). The only thing that could have made things worse is if my computer had lost power in the middle of my work.

Having had quite enough of the intermittent power drops that come with living in this apartment, I recently installed a UPS (as you know if you have been reading this blog). Sure enough, while I was deep in my work - probably in one of the most critical moments of the project I was working on - the power in the shop went out. But this time was different.

The computer stayed on!

I didn't lose a thing, but I did panic a little. I had no idea how long the UPS could supply power (I still don't), so I began saving all my unsaved work. But, because I was scrambling in haste, thinking I only had a few minutes of power, I saved at least one file in an unrelated directory (and subsequently had to move it later, but that's another story).

The point of this story is that the UPS did it's job and saved my ass! My wife, who became aware of the power outage after our roommate informed her of the occurance (our roommate is the catalyst for many outages, since her refrigerator, microwave oven, toaster oven and who knows what else are all on the same circuit as my computers) anticipated that I might be going through the roof as a result. The power came back on before I had to shut down, and my wife came out to my workshop with a concerned look on her face and asked, "are you screaming?" I responded, simply, "nope - I have a UPS, now." She's the one who bought it for me, so she's the one to thank, but she said, "thank God!" Perhaps she just doesn't want to take the credit.

Time is a blur regarding the past few days, so I don't remember if it was that night or the following night, but I was still up hacking away around 3:00 am when a huge thunderstorm kicked up. That is rather unusual for this area. But, despite the UPS/surge suppressor, I thought it was best to shut down all the computers. After growing up in the Sonoran Desert and surviving many thunderstorms, I know better than to leave sensitive electronic equipment plugged in and turned on during the storms - including answering machines. So, down the computers went.

Except for my main PC.

I initiated shutdown on the Mac and it turned itself off almost before I could switch the monitor over to the PC (which is a simple matter of flipping a switch). I then initiated a shutdown on the PC. One has to wonder about these marvlous Microsoft Windows operating systems. It took forever to shut down. In fact, the storm was literally over (as far as the lightning part) before the computer finally shut itself off.

Anyway, I am now operating with more confidence, knowing that power failures are no longer going to result in lost work. My next step - and I may do this today - is to install a backup hard drive in my PC and mirror my data.

Speaking of data recovery... I reported in the blog recently that I performed a data recovery operation for a friend of mine who had an ailing system drive. He has since reported back to me that the recovery operation was 100% successful and that his system is now running smoothly and quickly "like the day [he] bought it" and that I "exceeded all [his] hopes." That's what I like to hear! It was a very gratifying feeling.

Last Wednesday (a week ago, already? Seems like yesterday) I went to the annual "junk exchange" at the Home Brew Robotics Club, hoping to get rid of some stuff. Instead, I was only able to unload one item (in trade for a CMUcam!) and came back with another additional item: a 20GB hard drive. Whoopie. Anyway, I have the hard drive connected to my PC, now, and it works fine. But, the thing is five years old, so I won't trust it to critical data, but at least now I have something to "play" with when experimenting with disk configurations or data recovery tools. I am half thinking about doing data recovery on the side for people - affordable data recovery - once I get my system all backed up.

I have another computer that I keep trying to use to learn Linux on and to set up as a replacement for the Linux server that I have now, but I just never seem to find the time. And the thing about the Linux server is that it just runs and runs and runs. If it dies, I won't know how to fix it. The thing stays on for months at a time, and I have no idea of its status, etc. In fact, as I sit here writing this, I am wondering if I even remember how to log into it. It is running "headless" (which means it has no monitor attached) and I don't quite remember what I had set up to connect to it (an ssh client somewhere?). And, what's my password?

That's the latest on the Computer Circus front. I have been hitting JavaScript pretty hard the past few days, but nothing really to report there. Just feeling the burn, stressing over the prototype I was making for the job interview. I think I nailed the job interview, by the way, so I may be working again, soon. If that happens, who knows when I'll ever have time to update my blogs any more.

Time will tell.

---

Speaking of time, a very strange thing just happened. I posted this entry to this blog and noticed the time on my computer was two hours behind. What the hell? I have also noticed that since my data recovery effort of a couple weeks ago, the boot up screen for my Windows XP Professional machine no longer says Windows XP Professional - it just says Windows XP - and the image looks old and grainy. Very strange. I have no idea what's going on there. There are bit mites in my machine! Get that backup going!

JavaScript objects are somewhat of a mystery, though the exact way they are implemented is not important to know how to use them. But I continually find interesting aspects about them.

Study the following code. Print it out and read it before going to bed if you need to (or if you just need to get a good night's sleep). I'm going to pick it apart in the text that follows it.

NewA.prototype.f = function() { 
    alert("NewA.prototype.f()"); 
}
function NewA() {
    this.a = 1;
    this.b = 2;
    this.f = function() {
        NewA.prototype.f();
        alert("NewA instance f()");
    }
}

NewB.prototype = new NewA();
NewB.prototype.inherited = NewA.prototype;
NewB.prototype.f = function() { 
    this.inherited.f();
    alert("NewB.prototype.f()"); 
    if (this != NewB.prototype) {
        this.f1();
    }
}
function NewB() {
    this.b = 3;
    this.f1 = function() {
        this.inherited.f();  
        alert("NewB instance f() -- a="
            +this.a+", b="+this.b);
        delete this.b;
        alert("b = "+this.b);
    }
}

// -- Main code --
var oA = new NewA();
var oB = new NewB();
alert( "Calling oA.f()" ); oA.f();
alert( "Calling oB.f()" ); oB.f();
alert( "Calling NewB.prototype.f()" );  NewB.prototype.f();

.
I think this example illustrates some interesting aspects of objects and "inheritance" as seen from the perspective of JavaScript. It is ever more clear to me that JavaScript's object-oriented paradigm is not as complete or straight-forward as in other languages...like Delphi. But then I think Delphi is king in that area, anyway, so perhaps I am biased.

Let's first examing object NewA. NewA does not inherit from anything, so it inherits the Object type properties by default. I expanded the NewA object by adding a function, f(), to its prototype. I also defined two instance properties, a and b, within the constructor. I then also defined an instance method, f().

By doing this, however, the instance method f() overrides the static method f() defined in the prototype. Therefore, any instance of the NewA object will execute the instance version of f(). Note, however, that within the instance version of f(), a call is made to the prototype version of f(). In the main code, an instance of the NewA object is created, oA, and then a call is made to oA.f().

The result of the line that calls oA.f() will be three alert windows that pop up in sequence in the following order:

  Calling oA.f()
  NewA.prototype.f()
  NewA instance f()

.
This indicates that the code in both the prototype version and the instance version of the f() method were called. Remember that in JavaScript, properties defined in the prototype are available to all instances of an object. So, for example, in the following code:

Obj.prototype.a = 3;
function Obj() {
    this.b = 7;
}
var obj = new Obj();
alert(obj.a);
alert(obj.b);

.
two alert() calls display the values of a and b, which in this case would be 3 and 7, respectively. The property a is a "class" property, or rather, a property of the object's prototype, but because obj is an instance of that property, it "inherits" the value of a (which is really to say that the static value of a in the prototype is visible to the instance as if it was a property of the instance).

However, if you look back at the code for the NewA object, the prototype version of f() was reference explicitly as NewA.prototype.f() and not through the this property. This is because the prototype's version is not part of the instance of the object and, therefore, cannot be addressed through this. On the other hand, this.f() refers to the instance version of the method. If one were to call this.f() from within this.f(), this would create a recursive condition which, in this case, would continue until the browser ran out of memory, likely causing it to crash.

Now let's look at the NewB object. NewB inherits from NewA. This is accomplished in the statement NewB.prototype = new NewA();. The interesting thing here is that you might think that NewB.prototype is now an instance of NewA, but this is not entirely true. If you were to call NewB.prototype.f(), what do you think would happen? You might think it would invoke the instance version of NewA, but it doesn't; instead, the static version is called. Only the static properties and methods (i.e. those defined in NewA.prototype) are available to NewB's prototype.

Prototypes do not carry instance properties (directly, anyway) and are thus not aware of them. You cannot access a or b from the NewA object through its prototype - only through an instance of the object can they be referenced, because they are not defined in the prototype. However, if you reference a prototype, directly, such as to call NewA.prototype.f(), the method has a this property available to it. Although, in this case, even if it is called from within an object's instance, this refers only to the prototype.

This is why in NewB, which also defines an f() static method, there is a test to see if this refers to NewB.prototype before referencing this.f1(). Although, this is going to take some additional explanation to describe what all is going on here.

Let's back up a little and look at the rest of NewB. NewB defines a static property called inherited that I created as a convenience to refer to the prototype of the inherited NewA object. This makes it a little clearer within the code of NewB methods when referring to static methods from then inherited object. Again, keep in mind that only the static properties and method of the inherited object can be accessed.

As mentioned, a static method f() is defined. The first thing it does is call the inherited static f() method from NewA. It then displays a message indicating it is executing the static version of NewB.prototype.f(). Then there is the test I mentioned to determine if it is safe to call this.f1(). The f1() method is defined as an instance method for NewB within its constructor. The reason this test is here is because the static f() method can be invoked either through an explicit call to NewB.prototyp.f(), or through a an instance of the object, such as oB.f().

The f() method can be called through the instance through the normal mechanism of instances "inheriting" all the static properties and methods available from the prototype. There is no instance version of f() defined, so the prototype's f() is called. When invoked through an object instance, the this property refers to the instance of the object, and not to the prototype. Therefore, since the NewB object does define an instance method, f1(), this method is available through the this property and can be called. If NewB.prototype.f() is invoked directly, no such f1() method is available.

Now, remember that a and b from NewA cannot be accessed through NewB.prototype. However, any instance of NewB will inherit the instance properties of NewA and will appear within the NewB instance. However, NewB turns right around and defines a new b instance property of its own, which overrides (or hides) the value inherited from NewA. This now makes it impossible (without deleting the b instance property from the NewB instance) to access the value from NewA, as method f1() will illustrate.

The f1() instance method calls the inherited static method f() method from NewA, then displays the values of a and b, then deletes the local instance of b and then displays the value of b. This produces what may be a surprising result if you missed my previous exploration of JavaScript objects.

The statement in the main code that calls oB.f() produces the following sequences of output messages:

    Calling oB.f()
    NewA.prototype.f()
    NewB.prototype.f()
    NewA.prototype.f()
    NewB instance f() -- a=1, b=3
    b = 2

.
Let's follow the trail here to see what happened.

oB.f() invoked the static method f() of NewB, since NewB did not define an instance version. The f()static method called this.inherited.f() which is the static f() method of NewA. This method reported the message "NewA.prototype.f()". Then the f() static method of NewB reported its message, "NewB.prototype.f()". Then, since this method was invoked through an instance of NewB, the this property refered to the instance, and thus had access to the f1() instance method, so f1() was called.

The first thing f1() does is, once again, call the static f() method of NewA, thus we see the next message reporting, "NewA.prototype.f()". Then control returns to f1() and the next message is displayed, "NewB instance f() -- a=1, b=3". The values of a and b are displayed, 1 and 3 respectively. This shows that the value of a was inherited from NewA, and that the value of b was defined by the NewB constructor.

Now an interesting thing happens. The b instance property is deleted and its value is then displayed. You might think that the value of b would be undefined at this point. However, the message "b = 2" proclaims otherwise. What has happened here is that instance oB no longer has an instance property b. However, since it inherited a value from NewA for b - in this case, 2 - then that value is still available to oB and thus appears. Now, if you were to assign a new value to oA.b (say, oA.b = 5) and then execute oB.f() again, the value of oB.b remains unchanged. So, this begs the question, where is this instance value stored?

Good question. I don't know.

So, now I wonder if there is any mechanism in JavaScript whereby one can access the inherited instance values? If so, I haven't found it, yet, and it's also kind of awkward to have to go through the steps I illustrated here to access inherited static properties and methods.

Other questions I hope to explore in JavaScript is how a function can be an object, too. For example, I can define function X() { alert("do something"); } and then turn right around and add a property to it, like X.a = 5; I can refer to X.a to get its value, or call X() to invoke the function. How can it represent code and structure at the same time?

Enquiring minds want to know.

In fact, if you really want some confusion, try something like this the next time you are poking around:

function X() { alert("a = "+X.a); }
X.a = 5;
X();

.
Stay tuned for more JavaScript mind benders...

So, I have been using JavaScript off and on for years now, never really digging very deeply into it until recently. I am now playing with the object oriented aspects of the language.

Objects in JavaScript differ fundamentally in certain ways from other object-oriented languages (like Delphi, for instance), and I just learned some peculiar aspects about them today.

In JavaScript, everything that is not a primitive data type (such as a number), is an object. Even functions are objects. And, since JavaScript is interpreted and not compiled, it does things a little differently that allow you to define objects and object properties on the fly.

There is no explicit "Constructor" keyword to identify an object's constructor. An object's constructor is a function, just like any other function, and could be indistinguishable from any other function if you didn't know what you were looking at. But the name of the function is the name of the object "type", if you will, that you want to create. The actual object creation is performed by the "new" keyword.

So, if you had a constructor like the following:

function Robot( dangerous ) {
    this.eatsPeople = dangerous || false;
}

Then, you can create an instance of this object by doing something like this:


var killerRobot = new Robot( true );


Now, there are a few things to explain here. The first has nothing to do with objects. If you notice in the Robot() function, the assignment uses a strange and seemingly pointless Boolean expression: this.eatsPeople = dangerous || false; Since "dangerous" is a boolean data type (well, not explicitly, but that's how it is being used), then what is the point of "dangerous || false"?

The thing about JavaScript is that you can call the Robot() function without any parameters, and it will still invoke the Robot() function. So, if I were to say


var friendlyRobot = new Robot();


It would invoke the Robot() function, but the "dangerous" parameter would resolve to the value of "undefined". And, in a conditional statement or expression, dangerous does not resolve to "true" or "false" - its value is always "undefined", which is not really valid in a Boolean value, so it must be translated somehow. When JavaScript evaluates a logical "OR" expression, it will continue to evaluate each term of the expression from left to right until one term succeeds, or the last term is evaluated, whichever comes first. Boolean "OR" evaluation is short-circuited when the first true condition is encountered, and the result of the expression is the result of the last term that was evaluated. Therefore, "dangerous || false", when evaluated, first looks at "dangerous". Its value is not "true", so the term fails and evaluation progresses to the next term of the expression. The next term is simply "false", which resolves, literally, to itself ("false"). The term fails, but there are no more terms to evaluate, so evaluation ends there and the final result is "false". Therefore, the property "eatsPeople" is assigned the value of "false".

If the expression was:


this.eatsPeople = dangerous || true;


then this.eatsPeople would be assigned the value of "true" if dangerous was "undefined". The only problem with doing this, however, is that this.eatsPeople will be set to true regardless of the value of dangerous.

So, anyway, enough of the sidebar. Notice the reference to "this" in the Robot() function. "This" refers to the current object in question. Since the new keyword results in the creation of an object, this is a signal to JavaScript to create an object, and - in this case - call the Robot() function to act as the constructor. The "this" reference in the Robot() function then refers to the new object just created. And the assignment to "this.eatsPeople" is actually defining a property for the instance of the Robot() object, even though there is no "var" keyword attached. This is how you can define new properties for objects on the fly in JavaScript. In this case, the property is created within the constructor.

In the main code, I could further add another property to my robot's instance if I wanted to, like this:


var killerRobot = new Robot(true);
killerRobot.reproduces = true;


This adds a new property "reproduces" to the killerRobot instance. Now, the important thing to remember here is that the reproduces property only exists on the killerRobot instance. If I created another instance of Robot, it would not have the reproduces property. In order to have all robots of type Robot, the property needs to be added to the Robot() constructor, so now the constructor might look something like this:

function Robot( dangerous ) {
    this.eatsPeople = dangerous || false;
    this.reproduces = false;
}

This would make all Robot instances friendly and alone by default. An additional parameter could be added as well to specify both properties in the constructor, but we won't do that here.

Now, one not-so-apparent thing to note here is that these properties are what is known as "instance" properties. In other words, they are properties that belong to the instance of the object and not to the object "class", itself. I hesitate to use the word "class" in the context of JavaScript objects, because JavaScript does not particularly include such a notion. But, because there is no formal "class" declaration available, there is no formal equivalent to a class property or a class method.

However, there is something comparable. For each object type in JavaScript, there is a "prototype". By assigning things to the prototype property, you can define properties and methods that are shared among all objects of the same time.

This has always been my concept of object-oriented constructs all along - that all instances of a class share the same exact code. But in JavaScript, if I were to add a method to the Robot() object in the following manner:

function Robot( dangerous ) {
   this.eatsPeople = dangerous || false;
   this.reproduces = false;
   this.attack = function( target ) {
        alert( "I'm going to kill "+target+"!" );
   }
}

then I created two robots:


var killerRobot = new Robot(true);
var friendlyRobot = new Robot();


then each robot would have its own copy of an attack() function (even though friendlyRobot will probably never use it). This is contrary to other languages, such as Delphi, where you have a class that defines the methods (such as attack), and only one instance of all those methods exists and are available to all instances of that class, whether used or not.

The way to achieve this in JavaScript is to use the prototype property (though I'm not really sure it is a property). For example:

Robot.prototype.attack = function (target) {
    alert( "I'm going to kill "+target+"!" );
};

function Robot( dangerous ) {
   this.eatsPeople = dangerous || false;
   this.reproduces = false;
}

Here, the attack method has been moved out of the constructor and up into the Robot object's prototype. This way, the function (method) is available to all instances of the Robot() object.


var killerRobot = new Robot(true);
var friendlyRobot = new Robot();
killerRobot.attack("friendlyRobot");
friendlyRobot.attack("some time");


The above code would produce the output:


I'm going to kill friendlyRobot!
I'm going to kill some time!


and with only a single instance of the attack() function in memory.

But now here is an odd thing about JavaScript objects. All the properties defined within the constructor exist only on a per-instance basis. In other words, I have to create an instance of a Robot in order to have access to properties named eatsPeople and reproduces. I cannot reference the object "class", itself, for such values. This is expected, since each instance is likely to have different properties (that's why properties exist, eh?).

What if these properties were moved into the Robot's prototype?

Robot.prototype.eatsPeople = false;
Robot.prototype.reproduces = false;
Robot.prototype.attack = function (target) {
    alert( "I'm going to kill "+target+"!" );
};

function Robot( dangerous ) {
   this.eatsPeople = dangerous || false;
}

Well, then, as you can see, we no longer need to assign this.reproduces = false in the constructor, since a definition already exists in the objects prototype. All Robot() objects will "inherit" a value of "false" for reproduces.

The same is true for the eatsPeople property. However, there is something that may not be so apparent happening here. If a robot is created, such as var killerRobot = Robot(true); it "inherits" the eatsPeople property value from the prototype...but the property does not actually exist as part of the instance of the robot. However, the Robot() constructor assigns a value to this.eatsPeople, which actually creates an instance property of that name for that particular instance. The value on the prototype is still there - the instance just can't see it any more.

This can demonstrated. I got to thinking about it, and came up with the following code snippit, tested it, and it produced exactly the results expected. Actually, let's demonstrate this using the Robot object to avoid veering down another path.

Study the following:

Robot.prototype.eatsPeople = false;
Robot.prototype.reproduces = false;
Robot.prototype.attack = function (target) {
    alert( "I'm going to kill "+target+"!" );
};

function Robot( dangerous ) {
   this.eatsPeople = dangerous || false;
}

// -- main code --
var killerRobot = new Robot(true);
alert( killerRobot.eatsPeople );  // Displays "true"
delete killerRobot.eatsPeople;    // Remove instance value
alert( killerRobot.eatsPeople );  // Displays "false" - NOT "undefined"!

In the main code, an instance of Robot is created, called killerRobot, with a value of "true" in the parameter to set the eatsPeople property to "true". Displaying the value of eatsPeople verifies this is the case. Now, the next line deletes the eatsPeople property. You might think that displaying the value now would display an "undefined" value. But this is not the case. In fact, the value "false" is displayed. This is because the instance property eatsPeople has been removed, but the prototype's version is still there...and the reference to killerRobot.eatsPeople resolves to the prototype's value.

So this seems to beg a modification to the Robot() constructor. Since the prototype's default value is "false", there is really no reason to clutter up memory by creating another instance of eatsPeople with the same value, so why bother creating it if the value of dangerous is false or undefined? It seems we only want to override the default value if the new value is "true". Therefore, to save memory, we can do the following:

function Robot( dangerous ) {
   if (dangerous) this.eatsPeople = true;
}

Got that?

OK, now if I really wanted to spend the time to dig deeper here, I would get into the aspect of how functions are actually objects, too, and how you can define properties and methods (i.e. other functions) on functions. For example, Robot.speedLimit = 35; or Robot.reproduce = function (dangerous) { ... };. This sets up the equivalent of "static" or "class" properties and methods, meaning thay can be referenced and invoked without the need to work from an instance of the object.

But I won't get into that now. Go rest, now. You deserve it.

There has been quite a bit of data loss going around lately. Just before it all started happening, I got this sickening feeling in my gut like it was going to happen to me. But, so far, it has only been on the periphery.

A friend of mine called me up to say that his computer was running slowly. I tried to troubleshoot it, but it started moving again, so the problem eluded me. I didn't know it at the time, but his system drive was beginning to fail.

A friend of his was working on designing a new web site for us and his computer crashed, causing him to lose all his work.

The other instances escape me at the moment, but I recall someone else was having trouble or just suffered a disk crash. It is never fun when a hard drive dies.

Even before all this happened, my wife knew I was concerned about data loss, especially since the power keeps going out in the shop, and she called me from CostCo one day asking me about a UPS (Uninterruptible Power Supply) that she was looking at. It turned out it was an excellent deal, so she bought it.

The UPS is now protecting my computers against power surges and power failures.



Shortly thereafter, my friend shipped his ailing drive to me and ordered a new drive and had it shipped to me as well, since I'm the guy with the data recovery tools. Or at least I thought so. Without going into the laborious details, I spent a day and a half on the operation. Nothing is ever easy.

I had a RAID controller that caused me much grief in the past that I was hoping to use to make an image copy of the sick drive, but it didn't deal well with media errors, so it quit. I then tried some other tools with some success, but it left the new drive unbootable. In the end, I finally downloaded the latest drivers, etc., for my RAID controller and was able to create an image copy of the drive, sans bad sectors. The jury is still out as to whether the OS will boot once it is installed back in the host machine - since I just dropped it back in the mail - but I am hopeful that the operation was a success.



The old drive was 30GB, and the new drive was 80GB. I used to own the computer (and the 30GB drive that was in it), so this incident could have been my own. In fact, I fear that I could have a problem, since I am currently operating with a 120 GB drive that is not backed up. I have two 120 GB drives (in the picture above) that were used in an earlier recovery operation when I did lose access to all my data (as a result of my RAID card, and a horrible thing called "dynamic disks", thank you Microsoft). I have been waiting until I can sit down and finish writing a program to validate that I did, in fact, recover all my files intact (I didn't trust the buggy data recovery software that I used at the time), but I think I'm playing with fire by continually waiting. I think the waiting is over and I need to install one of these drives so I can back up my existing 120GB drive that currently has my life on it.

I actually haven't had my computer case open in a while, so it had plenty of time to collect dust. Ick! Look at all that nastiness!



So, my next step is to install the backup drive and clean out the dust. After that, I am going to configure another computer that we are not currently making good use of, to be a file server with some backup software running on it that works over the network, so I can save my critical files in an "off-site" manner. That way, if my computer gets struck by lightning or hit by a meteorite and both drives are killed, I will still have a backup of my data.

Whew!

With computers, it is only a matter of time before something goes wrong. That is why I started this blog in the first place - I knew there would often be plenty to write about.

I have had this feeling for a while now. A feeling of worry. I am worried that my 120GB hard drive is going to crash - the 120GB hard drive that has all of my creations on it. All of my data. All of my programs and email and pictures.

Everything.

I have not taken the time to set up another RAID since the first attempt that caused me so much incredible grief (but was fortune enough to recover from). And just the other day, a friend of mine called to tell me that his computer is running really slow, and that the BIOS reported a SMART error when booting - which indicates that his hard drive is on the verge of failing.

This compounds my worry. Therefore, I am taking steps this week to attempt to set up another RAID configuration so I have a backup of the drive. I am also going to set up some backup software on the network to save my more important files onto a separate computer. Dual redundancy is always a good thing.

Also, I have been wanting to get a UPS for a while, since the power in this apartment is so intermittent. On the same day that my friend called about his disk crashing, there was a heavy rain storm, and the power went out in the apartment. Twice! I had all my computers on at the time and I lost some unsaved work, but not much. I just hate that I lose any work at all. I typically have a lot of things open, and the computer(s) remain on all the time, since I just sort of continually work as I go along from day to day.

Anyway, my friend sent his ailing drive to me so I can save it for him. In fact, it just arrived literally this minute (funny how that happens). He is also sending me a new drive that he just bought on ebay yesterday that will replace the ailing drive. I will create a mirror of his ailing drive (if all goes well!) on to the new drive and send them back to him so he can get back up and running. The new drive should get here next week.

Well, I'm off to do a little data protection planning. Keep your bits intact!