So ages ago, in internet time (or 9 months ago in real time), I set up a brand new machine, specifically for development with VS2005 and ASP.NET (because, well, it takes a dual core 2.66ghz, 4gb ram beast to be able to write a text file without your keystrokes backing up, but that's another story).

I'd set up a RAID 0 (that's striped), mainly for the added performance, which was pretty staggering. My intention was to pick up a couple more drives later and round it out to a RAID 0+1 (which I have in my server, protecting all my actual source, etc).

Anyway, a drive died, quite prematurely, and my machine is thus rendered a doorstop.

I sent off the RMA to replace the dead drive (still under warranty), and picked up 2 more to round the RAID out.

Then I discovered that the Gigabyte GA-965-DS3, otherwise a totally bad-ass mobo, doesn't actually do raid 0+1. It only supports a 2 drive raid, either RAID 0 or RAID 1. Doh! Tip to manual writing guy: Don't say things like...

"Before you begin

Please prepare

1) At least two SATA Harddrives...If you do not want to create a RAID, you can only prepare one harddrive.

..."

That is a quote directly from the manual.

In my book, the implication there is that you could use more than 2 harddrives in the RAID. Unfortunately, such is not the case.

So I went off to the local computer store and picked up a PCIE 4 port SATA II RAID card, thinking I'd slap it in and be done.

Nay, spoketh St. Ignacious PCMCIA of the holy hardware. That card is PCIE x4, and my Gigabyte motherboard only has 3 completely unused PCIE x1 slots.

Back to the computer store.

I could get a PCI SATA II RAID card, but SATA II drives can pump 3Gbps, whereas a PCI slot can only manage about 266MBps. Does seem right to build up a smokin' machine, then force it to breath through a pixie stick.

Ok, new mobo time.

Looks like the Gigabyte GA-965-DQ6 has all the bells and whistles, plus the right combination of RAID, PCI slots, ATI Crossfire compatibility, USB and Firewire, plus, it even has a serial port on the backplane, just right for hacking X10.

Note to self: Don't bother "presetting" up a harddrive that you might want to mirror in a RAID later. Both the Gigabyte built in RAID and Window's software RAID (via "dynamic disks") want to obliterate any disk they RAIDify.

The nice dedicated RAID cards (like the Promise Fasttrack), I believe can handle that. Hell, one I was reading specs on seemed to imply it could convert, on the fly, between RAID 1, 0, 5 or 0+1, provided you have enough free space. Now that's a good time!

A few days ago, I posted light-hearted jab about some computer problems on the ISS. Well, never one to walk away from an opportunity, karma visited yesterday with no less than a complete failure of one drive in a RAID 0 I have on my main workstation.
For those that have never run RAIDs, it stands for "redundant array of inexpensive disks" and you can run several different configurations.

• RAID 0 - striped, 2 drives contain various pieces of files, such that you get double performance because both drives can be busy writing and reading different pieces of the same file at the same time. You get almost twice the performance and still have access to the full capacity of both drives.
• RAID 1 - mirrored, 2 drives contain exactly the data between them. Speeds up read performance, and provided an online backup of data. You have 2 drives but the effective disk space of just 1.
• RAID 0+1 - striped and mirrored. Best of both of the above.
• RAID 5, 6 etc - Even better but typically requires higher end dedicated RAID cards.

I had set up a RAID 0 for performance, intending to add 2 additional drives and mirror the setup later, for fault tolerance.
Well, later didn't come quickly enough, it seems, and one of the less than 9-month-old Western Digital WD3200KS drives (sweet drives, BTW, unbelievably quiet and cool running), went belly up way before its time.
So, I'm filling out RMAs to return the dead drive and ordering two more to complete the full RAID 0+1 setup.
A question for anyone who's ever done this before. Can I setup a striped RAID 0 now, and add the 2 additional drives later to convert it to a mirrored/striped RAID 0+1 later, when the 2 drives come in, or do I have to have them all in place when I create the RAID initially?
Haven't had much luck finding an answer online.

I've recently read several blogs about how great Windows PowerShell is, so I decided to check it out myself last night.

I didn't get very far before I came across this on the download page:

"The .NET Framework 2.0 is required in order to install Windows PowerShell"

Ok, fair enough.

And then I proceeded to actually check out the download page, where they present no fewer than 20 different download options, including variants for "English" and "localized", x86 and x64, plus Itanium.

First, I know from experience that it would be almost insane to suggest that small development shops try to maintain 20 different downloads of what is essentially the same product. MS can get away with this because they've got lots of money to throw at the problem, but is 20 different downloads of a command shell utility really justified? Ok, some of them are for some MultiLingual UI addon, so the total versions of the utility iself is fewer than that, but not by much.

The bigger issue I have here, though, is that I thought, and MS would surely have everyone believe, that the .NET runtime and the JIT compiler within should automatically be handling the differences between x86, x64 and Itanium. That's the whole point of the JIT, right? The multilanguage versions? I can accept them, with reservations, but the different processor versions? I'm no expert on the PowerShell internals, but if it requires the .NET framework, that would seem to imply that it's managed code, which would imply that the JIT should take care of the differences between platforms. And if it's not managed code, why not? Is it that MS is saying that managed code is good enough for everyone else, but not good enough for them?

Reminds me of the discovery I made ages ago that Outlook communicates with Exchange via RPC, not via DCOM, even though DCOM was being pushed hard by Microsoft at the time. Another case of "good for you, not good enough for us", perhaps?

Oh, and PowerShell looks like a very handy tool for Administrators. I'm sure I'll find some uses for it eventually. But, get-childitems -path env: just to retrieve the current environment vars? There's something to be said for mapping all sorts of various available info like that into a consistent interface, but my stack's too deep as it is right now to pile this syntax on top just yet.

How's this for a rough IT problem. Apparently, the ISS is having some difficulties getting several fairly important systems back online after some problems.

Of course, if they need computer help, I'd love to offer to take a trip up to help debug things .

Wouldn't that be an awesome GeekSquad tech call!

There's an interesting opinion piece by Kathleen Dollard in last month's Visual Studio magazine. The latest issue has another piece by Kathleen that is very similar. There's no link to the latest one, because that issue has just come out (I got mine not 30 minutes ago).

In them, she's essentially saying that the .NET framework, and all the various supporting enterprise frameworks, have become so large that no one can hope to be competent enough in them to be able to intelligently determine what to use, when to use it and when to stay away.

I couldn't agree more. But despite comments in the article that she is "more optimistic today" and that "the revolution has begun", I still come away from the articles sensing a muted dread. Fear that suddenly, skills you possess today and have honed over the years will become worthless. The value of the knowledge you currently have is drying up like last weeks doughnut holes.

And I'm just not down with that.

That fact is, my experiences seem to suggest that the less you know about these high level frameworks, the better off you are. I'm not saying don't get familiar with them. I'm saying that if you spend time to learn the basics of computer functionality, hardware, interfaces, binary, and object oriented principles like encapsulation, polymorphism and inheritance, details of specific frameworks just tend to come out in the wash.

On the other hand, if you spend all your time focusing on a specific framework, when it's no longer de rigeur, you're screwed.

Microsoft has created some great stuff, to be sure, and some of the newest bits out of the pipe certainly seem compelling, WPF probably more so than anything else. But it's also thrown out plenty of red herrings, costing companies untold money before people realized that "the silver bullet of the day" probably wasn't a good idea after all.

Back to the knowledge issue though. When VB1 came out, and only a bit later VB3, everyone exclamed at how great it was because "you didn't have to know the nuts and bolts of the Windows API to get something built for Windows". Which was true, unless you wanted to build an program you could actually do something with.

The fact is, VB was like that first step down into the pool. It lets you get your feet wet and get used to cold water before you dive in headfirst. Plus you get to feel for sure whether there's any water in the pool.

But eventually, you either dive in, or you decide you don't like programming.

VB.Net has always been more like the diving board. You either walk away, or you dive in, and you won't know if there's water in the pool till you feel it or you bash your skull on the gunite.

I think there's a bigger issue here, though. Emphasizing all these layers of Linq, Sharepoint, WPF, WF, WCF, Ajax, and blah blah blah, won't help encourage anyone to dive in, and that's what VB.net needs to be doing. Instead we get, what, the MY classes. Puh..leaze! At least edit and continue finally came back with VS 2005. Where's the genius that decided it'd be a good idea to leave it out in the first VS releases, anyway?

Don't get me wrong. You can create some hardcore stuff with VB.Net, a lot easier than was ever possible in VB. But you get some hardcore baggage coming along for the ride too. And that's unfortunate, because falling CS enrollments may mean a pretty sweet employment future for me, but it bodes some not so sweet prospects for our long term technological advancement as a nation.

And dammit, I want my flying car before I GOTO END !

Completely unrelated to programming, but very cool anyway.

Mexican geologists discovered a cave filled with giant (and by giant, I mean some as much as 36 feet long) gypsum crystals. There is a great picture of it in the latest National Geographic.

At this point, I'd love to include a picture of one of the crystal caves, I'm just not sure about copyright issues surrounding doing so. I suspect it would be ok, but better to err on the safe side.

Anyway, check the full article here. Be sure the next through the pictures.

Reminds me of that really cheesy movie from several years ago, The Core. If I'm remembering correctly, they used a big drilling machine to drill to the earth's core, but on the way, they fell into a huge cavern full of giant crystals. In the movie, I think they were diamonds (of course). Life imitating art? Should I really call The Core art? I'm just not sure...

You are writing all your applications with a Client-Server architecture, right?

Oh, wait, this isn't the late 90's.

You are writing all your applications as 3-Tier assemblies, right?

Oh, wait, this isn't the early 2000's.

You are writing all your applications... Oh, to heck with it.

What's the architecture du jour these days, anyway, n-tier? x-tier? SOA? XYZ-PDQ?

So what's all the hubbub?

I propose something radical. Logically tier your code based on functionality, not locality. If you do that properly, monolithic, Client-Server, 3-tier, n-tier, x-tier, tears for fears, it won't matter.

Why not?

Because if the code is properly organized and logically tiered, you'll be able to easily move it wherever it needs to go to create (and remove) whatever tiers become necessary.

For example, I once worked for a company building a sizable billing package based on SQL Server. We wanted it 3 tier (Presentation, Business Logic, and Data Access), but we also needed it to be:

1. easy to debug and maintain, and I mean easy, not the "learn how to jump through hoops faster" easy, but really easy. The dev team was small. This was a requirement.
2. easy to deploy in a demonstration mode. If a prospect couldn't fire up a CD install and in 5 minutes or less be playing with it, it wasn't going to fly.
3. capable of scale-out deployment to accommodate multiple report generation servers, data analysis servers, etc.

In the end, we designed a server app as the BLL (it actually ran as a service), a database chock full of highly optimized stored procs as the DAL, and a fat client that contained not only the user-facing interface but also the entire server app internally. And the key to all this was that the code for the server was exactly the same code as was in the client. The code was literally shared between projects in our VCS.

When connected to an actual server component, it got all the benefits thereof. But for debugging, it was unbelievably efficient to have both the client and server right there running at one time not only in the same IDE, but actually as part of the same executable. And deployment was a snap because the demo install didn't have to bother with a server installation, it just created the DB and dropped the client on the machine.

If we'd needed to split functionality out farther, it would have been a very straightforward process because internally, everything was already split out.

The bottom line is:

Get the logical tiers right and encapsulate with a vengence.

Note to self: Vengeful Encapsulation. Sweet band name!

In my post here, I discussed a problem I'd run up against having to do with performing an ADMIN installation to a specific drive letter or network path, then unmapping that drive letter and remapping it to some other letter.

If you then attempt a client install, you'll get either at 1327 error (for mapped drives) or a 1606 error (if you used network UNC paths).

After further testing, it appears that the problem comes from assigning the TARGETDIR property to the AdminProperties property.

Some background:

The AdminProperties property is a ";" delimited list of property names that should be preserved when performing an admin install. The MSI engine stores those property values as they are at the time of the administrative install into the created Client Installation MSI (the MSI file that ends up in the admin install folder). Here's an example:

and a little closer in...

(Interesting bit of trivia: I have no idea how the MSI engine actually stores these properties in the MSI file, because opening the MSI file with ORCA, I couldn't find them anywhere. I'm guessing they're not stored as a normal table entry).

Normally, any properties you'd like to pass on to the client install (ie those collected via the User Interface during the Admin install), you would list as AdminProperties so the MSI engine will pass them on.

I had set the TARGETDIR property as an AdminProperty, because at one point, I believed it was necessary to preserve the path to the Admin installation, so the client installation could make use of it.

This turned out to be ill advised, however, because often, admin installations will be moved (for disk space reasons, reshuffling servers, etc), and preserving the TARGETDIR this way locked the Client install to always point back to the original administrative install. Instead, during a client install, I simply obtain the value of the current location of the MSI file (which, by necessity is the current location of the administrative install) and use it where needed.

At any rate, none of this should have mattered, because the documentation clearly states that the COSTFINALIZE MSI event checks the directory table for valid drive letters, not the Properties table.

However, directories stored in properties listed in the AdminProperties list are appearently special cases, and their validity is checked.

Moral of the story? Use InnoSetup

But, if ya gotta use InstallShield, make sure you do not:

1. Store the Admin Installation folder or any folder that might end up getting remapped or disconnected, into a property during the Admin install.
2. List that property in the AdminProperties property.

This goes for the TARGETDIR property (a common one), but also any other properties you might create.

Don't you just love strolling along merrily on a friday afternoon, thinking "My, the weekend is right around the corner, I believe I shall sup on crumpets and tea", when you step right through a soft spot on the ground in fall into a viper pit?

Ever seen this error before:

(The blackout is to protect the innocent )

It's an MSI 1327 Error Invalid Drive, indicating (surprise) that a specific drive is invalid.

Basically, I got it while testing the install of an application I'm working on.

Many Google searches and a call to MacroVision later, and I still didn't have much of an idea what was going on.

The drive letter in question WAS valid at the time I did the original administrative installation, but was no longer valid when I performed the client installation from the admin install.

To sum up:

1. Map a folder to DRIVE X
2. Perform an Administrative Install of your app to Drive X
3. Unmap Drive X and remap the same folder to Drive Y
4. Perform a client install from the administrative install that is now on Drive Y
5. BOOM goes the dynamite

Even more interesting, I tried the same installation steps, but didn't use a mapped drive. Instead, I used a UNC network path name, and then forced that network share to become invalid. I got a 1606 "Could not access Network location" message. Different error, but the same problem.

I turned on verbose logging for MSI and it recorded that the error occurred during the CostFinalize event. That event validates all folder entries stored in the Directory table in the MSI, but a quick perusal of that table revealed no references to the (now invalid) drive letter.

Macrovision support suggested trying the client install on another machine, which I did and got the exact same error.

Then, on a whim, I simply mapped a folder to that drive letter (the one in the message). Any folder, some share out on the network, didn't matter what.

Viola! She workee!

Long story short, apparently MSI takes a snapshot of the drive (mapped or UNC) when you perform an administrative install. Then, when you attempt a client install from that admin install, if the drive that was in place at the time of the admin install doesn't exist, you get the 1327 error (or if you used a UNC path, an error 1606). From what I can tell, though, it doesn't actually use that drive for anything.

If you used a mapped drive, just creating a mapped drive with the same letter is enough to make MSI happy and continue with the client install.

If you used a UNC path, things aren't so rosy. In fact, I haven't found a recovery for this situation yet, though I suspect one is hiding under an MSI boulder somewhere.....waiting......

I'm experimenting with a new comment style on the site.

Basically, the idea is to make comments look like they're speech balloons. Plus, I believe it makes them a little easier to follow. Here's an example of what it should look like now.

I saw this on a blog somewhere, just not sure where anymore, and apparently I cleared my browser history since then because I couldn't find it again.

I'd have preferred the Names to be on top, with the arrow pointing down into the comment, but dasBlog doesn't have any support for templated comment elements. You have to have that to move the actual pieces of the comment (the name, comment, and date, for instance). From what I have found online, they just haven't gotten around to it yet. That made modifying the comment item format, um, shall we say, an adventure.

This is the first round. It doesn't seem to work completely in IE (the little dialog arrow doesn't show up), but it doesn't completely mess things up either. It looks right in FireFox. Not sure about other browsers.

The trick, as I've got it now, is that I'm using the AFTER pseudo-element along with the CONTENT keyword to create an image tag where there was none before, like so:

.commentPermaLinkStyle:after {
 content: " " url('quotearrow.png');
}

Unfortunately, this doesn't appear to be handled properly by IE. I tried a background img, but that didn't seem to work well either.

CSS, one giant, turbo-charged erector set full of parts that don't always fit the same way :-(