Rants and raves >> Macro facility dropped from VS 2012 -- WTF?

Talk about taking the "up" out of "upgrade" I have just become painfully aware that "because les than 1% of users use it" the whole macro facility in Visual Studio 2012: gone!  Have they lost their fucking minds?

What they don't seem to get is that the macro facility actually represents an infinite number of feature additions -- sure some of them quirky, some of them niche, some of them only fit for the person that wrote them (some not even that) but regardless, AN INFINITE NUMBER OF FEATURES, custom fit to each of our likings!

Microsoft has become so selective about which features to keep or drop, so frugal and austere, but this move is PENNY WISE, POUND FOOLISH.  They have just ripped our ability to quickly, easily and painlessly extend VS UI right out from under us -- hey assholes, thanks for nothing!

What they also don't get is that macro record was the fast track to learning how EnvDTE works. Historically the docs for this have been sketchy and poor, but it didn't matter, we were almost always only a recorded macro away from the set of building blocks we needed, or at the very least, a solid jumping-in point.

And to think some people on the social forum tried to offer AddIns as a substitute -- gah! Pain in the AddIns more like, they take significant time to develop, the "manager" isn't one, loading/unloading is broken, you have to copy stupid files to stupid directories -- I'll bet them a BRIEF keyboard compatability AddIn that less than 1% of those that use macros, develop AddIns.

As I was posting something a whole lot like this on social, I was struck with an epiphany: the feature usage numbers they have been using against us must surely come from those "send feature usage reports" things to which they always want us to consent... So what percentage of *all* users do those guppys that do consent, represent?  Did it ever occur to them that those folks are most likely NOT accurately represetative of the developer community as a whole. They're probably mostly young ones who haven't been thrown under a bus enough times to deeply distrust Microsoft -- yet!

I wish I could convincingly state that crap like this will be their downfall -- in a perfect world it would be.  But in this one... in exactly the same way that a wildfire growing so large it makes its wind is never a good thing, it is likewise not good that a corporation can lead an industry by virtue of size alone... this latest feature drop would be case in point.

Broken By Design:

[Open Letter to Microsoft ADO.NET Team, re: DataTable DateTime column "mode"]

I just want to say what an unfathomably POOR design choice it was to make "Unspecified Local" the default -- actually I question whether that mode should even exist at all!
 
Given that, prior to SQL 2008, all stored dates were effectively mode "Unspecified" (and that, in practice, the vast majority of DB-stored date values are still that way today) "Unspecified Local" is the worst case choice, it sets up data mayhem, and adds meaning to the word quirky.

It would've been nice if DateTimeKind could've been respected when assigning DataRow field values -- surely the offset could've been adjusted accordingly per row -- but nooooo, "you get one DateTimeMode for the column, across all rows, and you'll like it!"

What's worse, this mode literally begs for data corruption, during that interim while a developer has yet to perceive he has been thrown under a bus! For those unlucky enough to test on a server in their same time zone, the false sense of security this mode fosters is nothing short of negligence.

Until this moment I have been very pleased with ADO.NET, it's capabilities, flexibility and performance. Now I must question all assumptions, because as design choices go, "Unspecified Local" as default mode is just plain idiotic.

The icing on the cake is that this hasn't been changed over 2 releases of the framework -- consistency is only a virtue if you're not a screw-up! I'm sure the concern is the havoc it would wreak to change it at this point (pity that wasn't considered prior to 3.5's release) but there is a way to make it infinitely more usable, without breaking all the code that has surely been written to skirt this lunacy, so simple it's childish:

Add a DefaultDateKindMode directive, and change DataReader to respect it. Simple. Efficient! Not painful for the developer at all (forget excruciatingly so.) Let us make an intelligent, informed choice when we create a DataTable (because you are obviously incapable of such.)

Posts recently updated

The BRIEF keyboard for Visual Studio post (and attached project) has been updated recently.

Also updates, the AT&T Wireless Not-CSV converter/SQL importer has been updated to compensate for their latest atrocities, as they continue to butcher the CSV concept with reckless abandon.

Probably the best way to be kept abreast of these updates would be to post a comment and subscribe, I'll add a comment whenever I update a post.