Of iGovernment by Crony, and iBlogs

William Safire, in his inimitable concise style, writes in his weekly Times Magazine column from this Sunday about "When was the lowercase i before an uppercase anything born, and what did it stand for?"

He goes on to record that the first "i-product was the iMAc in 1998." This led to the iBook, followed by Apple's iPhoto, iTunes and of course the iPod. The meaning of i went beyond Internet, to be taken as "individual", "integrated", "interactive", or "what I want when I want it". Other companies jumped in. A furniture company calls its massage chair "iJoy".

So keep on the lookout for the iBlogs. I'm sure they are coming. Mine shall remain an "UnBlog", which means, very simply, that it isn't one.

Now of course since Miers has gone to the wolves, devoured by both Democrats and Republicans alike, we are presented with Alito, which suggests, as Safire laments, that it's back to "Government by Crony" (or perhaps, "iGovernment?"). But the fight brewing (and it will be a big one) isn't about judicial philosophy, experience, or whether you are Conservative or Liberal. What it's about is ABORTION.

And that's too bad, because it's a very minor facet of the big picture. The Supreme Court has already long since made its views known on the subject, and the Conservative "base" is attempting a stab at revisionist history. Conservatives bitch a lot about "left wing judicial activists". Since when is attempting to sway the Supreme Court to the right for the sole purpose of overturning Roe v. Wade not "right wing judicial activism"?

It's filibuster time again. Another nasty way to waste our tax dollars instead of having a hearing and voting up or down, which is what I thought we are paying Congress to do.


Visual Studio 2005 and SQL Server 2005 available on MSDN for subscribers


If you need help uninstalling beta versions, Aaron Stebner, MS Developer extraordinaire, has posted the latest versions of his "uninstall and cleanup tools" here.

Really, these work better and faster than using "Add / Remove" from Control Panel anyway :-)

Stebner has additional information that can be helpful in removing "unfound" versions of SQL Server 2005 Betas/ CTP's with the Cleanup Tool (that uses msizap) here.


Flash! Legitimate use for VB.NET found!

Yup. I believe I have found a legitimate, really useful (a la "Thomas the Tank Engine") use for Visual Basic .NET!

There are lots of scripts out there written primarily in VBScript that enable developers to do all kinds of cool things. If you aren't familiar with what I'm talking about, visit the TechNet Script Center and have yourself a look.

Now the cool thing is, you can paste a lot of this stuff into a VB.NET Class Library project, and all you need to do is massage the "Set", "wscript" and other VBS script-generic statements to regular old VB.NET Objects and fix up the code until "It Just Works"!

The key feature of this completely innovative and mind-blowing technique that most VB.NET afficionados will really like is that in order to make it really, really easy for yourself - you can Turn Off Option Strict and Option Explicit! ("What?", you say, "I already have them turned off...")

My Gosh! I've already (ahem) "written" a class library for my boss that enables and disables Network Adapters, and now I am "writing" one that allows you to add or delete an IP address to an adapter!

Will the wonders never cease? Long Live Visual Basic! (And apple pie, pumpkins, and the Rolling Stones...)


AJAX popular with home users, study shows

J.R. of Happy, TX reports he is using Ajax successfully on his SmartPhone. He says it "cleans up that small screen right nice".

In other news, a woman from Newburgh, NY is reportedly suing the Colgate-Palmolive Company over a hot bottle of AJAX that spilled off her washing machine and ruined three dresses.

Jack Spratt of Horse, IN reports that he uses AJAX every morning to clean his bathroom. Jack says that the product "doesn't mess up the UI of my bathroom mirror " and "there's no flicker or page reload when I flush the toilet."

Meanwhile, blogger Don Hopkins reports "AJAX is like cocaine: it seems glamorous until you actually start using it, then the unintended consequences totally f**k you up."

Hopkins posts the "Special Hazard Precautions for AJAX":


And Otis ThunkelDinger of Mudville, TX exclaims "Well, butter mah butt and call me a biscuit! That AJAX done called me back on my cell phone before the page done come up in Internet Exploder!"



WDTA= "What Does This Affect".

Yup. Came up again. Other developers came to me with a classic engineering problem (One of those, "Uhh, we think we shot ourselves in the foot", how do we fix it" kind of deals).

They were storing Xml documents that represent classes in the database in string form. Problem is, they didn't add a column to show the Version of the class / xml that was stored.

And of course, one ambitous developer modified the class in their DAL, and now when they retrieve the Xml, deserialization fails. He didn't ask that magic four word question that developers should ALWAYS ask when making a code change: "WHAT DOES THIS AFFECT?".

What's the answer? A simple answer is to add a column to the table that specfies the class version that is stored in the varchar or Text field of the table, and to mirror this
in some sort of constant string field in the class that is to represent the deserialized xml string. So when you pull the xml out of the database, you will automatically know which class it is supposed to be deserialized into. A better solution would be to store the assembly namespace.classname as the unique key. This way, you could even load the assembly dynamically at runtime if you needed to. For example you could have MyDALJunk.ClassDoSomethingCool1, MyDALJunk.ClassDoSomethingCool2, etc. as the version column items in the database table, and the compiled assemblies on the filesystem for these classes would be named exactly the same.

As far as matching up old records with new, I suppose you could write an XML -> XML XSL Transform to map the old documents into the new, or if it is simple, you could just eyeball the old guys and "Fix them up" by hand, and re-save them.
In this particular case it seems the "new" xml just has new elements but they aren't populated (yet). So the easy answer is to grab a dataset of the records that need to be changed, deserialize each row's xml column into an instance of the "old" class, then create an instance of the "new" class and do a node-for-node replacement, then serialize the "new" class and update the row in the database with it.

And of course, as one intelligent commenter has already posted, we could have unit tests too. I didn't even mention this in the original post, even though I recently wrote a review of James Newkirk's excellent new MS Press book on TDD. But of course, you need to be able to crawl before you can walk, and for a lot of developers, asking them to create and maintain test fixture code for NUnit is like asking a baseball player not to spit.

But the bottom line message is simple: Ask the magic question "What Does This Affect" whenever you are going to change code. Then you won't have to spend as much time going backwards, right?


"The Generation of Random Numbers is too Important to be Left to Chance"

I just had to laugh this morning when I read about somebody finally hitting the winning number in the PowerBall lottery, which had gone for 20 rollovers without a winner. People do the silliest things:

"Mary Neubauer, spokeswoman for the Iowa Lottery, said hundreds of ticket buyers had played a set of numbers from the ABC drama "Lost," which featured a character who won $156 million by playing a string of digits obtained from a patient in a mental institution: 4, 8, 15, 16, 23 and 42."

I'm getting the idea now. Television actually DOES reduce your IQ!

By the way, the famous quote in the title is from Robert Coveyou, the noted physicist who was chief of the Manhattan Project that built the first atomic bombs.


On Technical Books, Accuracy, and "Holier than Thou" pedantic attitudes

Among my other travails in the .NET world, I've been serving as a Technical Review Editor for a couple of upcoming .NET related books.

You see some interesting and occasionally VERY ANNOYING statements made by various authors when you get to review these chapters. It becomes obvious (especially with .NET 2.0 where authors are often "rewriting" their 1.1 books, and more often than not, they aren't adding much new value either) that we are making statements and proclamations out of habit, even when they are DEAD WRONG, simply because some tech reviewer from the previous book didn't catch it.

I'm not naming names, because that's not the point. The point is, authors should take GREAT PAINS to get their facts straight. If I am a "noob" and I buy and read your book and accept information that you give me in the confidence that it is factual, and it turns out not to be so, you have done me an egregious disservice and hurt not only me, but yourself, your publisher, and the rest of the technical publishing landscape.

Last night I got so confused by two related "best practices pronouncements" in a book I'm reviewing that I actually had to write a short program in C# 2.0 to prove to myself that if I pass a DataTable (a reference type) into a method, and modify a column's value inside the method, that the ORGINAL Datatable will be modified! This is one of the most egregious and poorly explained language facts, reference types are passed by reference by default, it doesn't matter if your method is getting a "COPY" of the reference, the point is if you modify the object inside the method, YOU ARE MODIFYING THE ORIGINAL OBJECT. Period! You can put the "ref" keyword in front of the parameter, or leave it out. It won't make a bit of difference.

Just a word to the wise:

If you are an author, take the time to get your facts straight, and once you have, be sure that you can explain them very clearly.

if you are a reader, don't trust everything you read!


Will the new bull market in Gasoline spark a Telecommuting Boom?

Just a thought that popped into my head after looking at the charts of NYMEX unleaded. No question that gas is in a new bull market, OPEC is even considering reducing oil output, although the real problem isn't crude, its refining capacity.

If you own a gas-guzzlin' ESS YOO VEE and drive it to work and back every day, and you're the only person in the car (at least that's what I see from the vantage point of my 29mpg Camry every day) then maybe you are thinking about this?

According to the experts, it's not that technology is an issue - it's your BOSS! From the Washington Post:

"Ronald F. Kirby, transportation planning director of the council of governments, said the main obstacle to teleworking is that some bosses worry about supervising workers 100 miles away. "There is a strong level of resistance by middle managers," he said, even though studies have shown employees are more productive when teleworking."

And more - -
"Private companies also are taking a second look at telecommuting. AeroAstro, an Ashburn-based satellite and space systems business, announced yesterday that it is urging its employees to telework at least one day a week because of the gas shortage caused by Hurricane Katrina.
Richard Fleeter, the company's president, said the policy, which will reduce employees' transportation costs by 20 percent, is a valuable recruiting tool. In a statement, he said the move would "attract to our work force the most highly talented people regardless of their geographic proximity to our home in Ashburn."

As an ex-stockbroker, I've learned that you can find out a lot more about what's going on in Dodge by eyeballing some good charts than by watching warm fuzzy "aren't we good citizens of the global economy" Exxon Mobil ads on TV.

We have a very big supply-demand problem with gasoline products, and it has little to do with the price of oil. A quick look at the first chart shows that while global oil demand has been steadily rising, refining capacity isn't keeping up:

This next chart makes it even clearer. Capacity peaked in 1981, and the actual number of refinieries in production has declined to only about half what we had online 25 years ago! Why is this? Simple: the big oil companies and refiners figured out about 20 years ago that by not only refusing to build new refining capacity but by actually shutting down refineries, they could artificially affect supplies and make more profits. Does this make you mad, or would you just say "That's capitalism..."?

Meanwhile, real pump prices have actually declined somewhat from their 1981 peaks. For those who understand inflation, 1979-80 was when then Fed Chairman Paul Volcker decided "enough was enough" and stood on the brakes with both feet (which took some real balls, by the way). The reason real prices aren't as high as then is mainly because we don't have the kind of commodity inflation and interest rates we had then.

And another chart that clearly illustrattes that refining capacity is declining despite growing demand, with some more recent figures.

Finally, we can see that the real prices of oil and gold have reached a disparity from their peaks in 1980, indicating that either gold is underpriced (not likely) or that oil is overpriced. This could indicate that price pressure on oil is about to collapse (partly due to conservation by shell-shocked hordes of gas-guzzling SUV drivers), but it still doesn't solve the basic problem which is: If you want to lower the price of gas, you either have to produce more of it, or consume less of it. The choice is ours.

So what's the answer? Bill O'Reilly, who apparently just doesn't "get it" about economics, seems to think that Big Oil should just voluntarily "give up" 20% of their profits. Won't work. What could work is to give them a combination of carrot-and-stick incentives / tax breaks to actually create more refining capacity. And for God's sake - have enough strategic sense not to put it all in one place, like New Orleans, huh? But the bigger picture solution is simply to create new energy sources. You know what? Back in the late 1960's we were able to put men on the moon, and we can't even seem to get the picture about energy independence after 30 years of experience with being dependent on foreign oil, since our first big attack of oil -constipation back in 1974. You elected officials in Congress - this ain't rocket science, guys and gals. How 'bout it?