Wednesday, August 31, 2011

Win8 Explorer's New UI

The IT Geek-world is in a something of an uproar over Microsoft's big reveal on Sunday (8/29) of the improvements that they're baking into Windows 8's Explorer.

Explorer has--at Microsoft's own words--been the foundation of the user experience of the Windows desktop.  And likewise, they've gone to considerable lengths to provide the first substantial change to Explorer in years.   There's a few... not necessary issues or concerns... but something like that which I, as a technologist, and specifically as a MICROSOFT/WINDOWS based technologist, have about not just the new UI, but what this new UI means in terms of the data provided by Microsoft at the linked to post above.

But first, as a Windows 7 user, there is at least one aspect of these UI changes with which I whole-heartedly agree, and that is the return of the UP button. I did not realize just how often I used that simple little command option while performing file-management tasks until it had disappeared. I think that was my biggest stumbling block when switching my OS over to Windows 7.

The second thing about Explorer and the Windows-file system that makes me happy is that there will be native support for ISO's in the Explorer. This is good news, especially for folks like me (and my company) who routinely store ISO's on the network for ease of backup and maintenance.

Now, the ribbon menu system itself, I'm less concerned over than most of the other IT blogs out there. I like the ribbon menu, and think it's a great mixture of a traditional menu and command bar that is ultimately more useful for end-users.

But I don't think that's going to be the case here. By Microsoft's own metrics over half of the entry points for Explorer-based commands is the CONTEXT menu (54.5%) with hot keys coming in as second (32.2%). That leaves less than 15% for the command bar and menu bar (and the command bar got 10.9%).  What this tells me is that users already aren't using the command bar or the menu. 

Oddly, Microsoft's reaction to this, is to make it--at least at first glance--more complicated.

Microsoft's Simplifies  Explorer
 Luckily, this apparent complication does provide some little pluses. The ribbon provides roughly 200 commands quickly and efficiently to the user. More importantly, the Quick Access Toolbar, allows for customizations for those most important commands.  But again, this is odd, since roughly 82% of all commands are as follows:
  • Paste (~20%)
  • Properties (~11%)
  • Copy (~11%)
  • Delete (~10%)
  • Rename (~8%)
  • Refresh (~7%)
  • Cut (~7%)
  • NewMenu (~4%)
  • CommandBar (~4%)
  • New (~2%)
When you couple that list with the fact that over half of the commands are accessed via the context menu, I as a technologist is left wondering exactly what's the point.

And the thing is, that this is aimed at the STANDARD USER. This is not aimed at power users, or network admins. In fact, the original blog post describing these changes goes out of the way to indicate as much, by pointing out that the roughly 200 commands found in the ribbon menu will now all support keyboard shortcuts.

Ultimately though, I understand the uproar, while not understanding it. I know from using Office that the Ribbon menu, once users "get" it, is better and more efficient.  Additionally, these changes to the ribbon are not aimed at those users who are currently in an uproar.  After all, it's going to be the power-users who read up on changes to Windows Explorer months before the associated OS is actually released.  

The thing is, is that this is a big change. Worse, it's a change which feels like feature creep and/or command bloat.  I mean, look at the menu, it's taking up more room, hundreds of commands are now exposed, and it's all shoved into a new interface.  This, when MS admits that ~82% of all commands used are the 10 listed above. 

Ultimately, I think a lot of the backwash is due to the smooth UI which was the first taste of Windows 8 in the video released a few months ago.  Power users and early adopters saw that new desktop experience, and started drooling, ignoring the fact that the desktop has little to nothing to do with the underlying file system or the explorer used to access it. 

Could MS have made this "sexier" or "sleeker." Sure. They could have taken Apple's OSX approach, and given dedicated applications to specific types of tasks.

But, I, as a developer, would be pissed at that. I use the file explorer extensively. I have to move artifacts back and forth between servers and even development-sandboxes on my own machine. I rename things. I delete things, I toss them from one folder to another to my desktop.

But that's at work (or while I'm working).  At home (or while I'm playing), I rarely, if ever, explore the actual depths of explorer; I'll access a few folders where I have media stored, and access a few applications, most of which are stashed in a DOCK application, and on very rare occasions, I'll move media either to my NAS or burn it to disc (or bring it back over to my machine for consumption).

Truthfully, I think this is something of a non-issue. IMO, it's only causing a row right now because of how it compares to the iPad and other tablet devices when Windows 8's first preview in the wild was based around a tablet interface (and more specifically, the promise which that preview held for tablet interfaces).

Sure, it may mean a bit more training time for new users (some of whom may still be coming from Windows XP). Sure, it may be a bit more confusing those first few weeks after adoption. Sure, it may not be as  sleek and stylish as the Mango interface.

But, as long as it does what I need, and stays out of my way while it does it, then I can live with all of it.

Friday, August 26, 2011

Hulu on the TouchPad

The tablet PC that
Hulu doesn't like
I purchased the TouchPad in its recent fire-sale, and overall, I'm quite happy with the device. I'm still considering placing Android on it once the various hackers out there get the process down to a science, but that's neither here nor there.

My issue that I'm a tad annoyed with is the fact that Hulu refuses to run on this machine.

So, of course, I immediately asked Hulu support why this was, and Hulu's response was:
Thanks for writing in about Hulu on the HP TouchPad. Unfortunately, due to the contractual agreements with our content providers, we have to have a certain set of agreements set up with a device manufacturer before we can provide support for that device. We have no partnership with HP at this time, so we can't currently stream through their device.
We get a lot of requests for webOS support, so it's definitely something that's on our radar. Though we can't support it right now, we are continually evaluating new technologies, and will be adding more devices based on user demand. Stay tuned!

We have plans to bring Hulu Plus to as many devices as possible. For up to date info on which devices are currently supported or have been announced, you can go to ( ). On this page, you can even sign up to be notified of availability on upcoming devices.
Which confused me a bit more. After all, a tablet is nothing more but a small-form factor PC. Why does the manufacturer of my PC matter when I try to access a website? It's not like the fact that I'm running a DELL matters when I access Hulu. I mean, does Hulu not work when people build their own gaming rigs?

So, I of course, pointed this logical fallacy out.

And got this... slightly condescending reply:
Thanks for getting back to us. The TouchPad is considered a device and as such to play our content on it requires certain licenses and approval of the owners of the content on our site. I know it's frustrating to have to pay for services you believe should be free. I'd love to speak to the issue.

When we launched the free service, our rights were limited to streaming on the PC. Unfortunately, mobile and TV devices were not included in these contracts, and in order to add them, we've had to do so under a paid service, Hulu Plus. This is for many reasons, including the high price of these types of streaming rights and because many shows required they be part of a paid service to be on these types of devices.

Once again, I'm sorry for the inconvenience. Please let me know if you have any further questions. Happy viewing!

There's two things that really got my goat here.

The first, the implication that a PC is not a PC. I'm a big fan of clarity of thought and word. I know the definition of a PC--it's a rather large part of my job after all.  For those of you who are wondering, a PC is a computer designed for use by a single person. I wouldn't expect to be able to stream Hulu to a SERVER since it's designed for use by multiple people, but tablets are designed for use by one person.

My OTHER Tablet that Hulu likes
Additionally, I KNOW that tablet devices can have Hulu streamed to it. I know this, because I also own a Viliv S5 tablet. And the Viliv device is a smaller form factor (though a thicker, and heavier machine) than the TouchPad. So it's not the size of the device--it's not the fact that it's a tablet that makes a difference to Hulu.

No, it's the operating system. It's the fact that the browser (which runs Flash) on the TouchPad tells Hulu that it's not a Windows device. In fact, I can prove this by using Fiddler to strip out my user-agent string from my HTTP Headers--let's just say that doing so, makes Hulu not play nice with Windows.

The second is that line about "have to pay for services you believe should be free." That makes a rather large assumption that I'm complaining about the cost of Hulu's services--which is not the case. Additionally, even Hulu's "free" service isn't free. There's commercials attached to the video--which is the traditional way that video services have always been paid for (just sit down in front of your television for proof of this).

And even more important in this regard, is the fact that if I was merely after free content, that can be had. It's easy to torrent a TV show--and a torrented TV show does not have commercials, and are typically of better quality than the flash-based video which Hulu streams out.

Regardless, this definitely leaves me in a mood to NEVER buy the Hulu service. After all, if they can't stream the standard service to my small form-factor PC which runs a linux-based OS and Flash, then why on earth would I assume that they could stream the HuluPlus version to my small form-factor PC which runs a linux-based OS and Flash?

And of course I asked them... which leaves me wondering if I'll get an answer...

Thursday, August 25, 2011

Red Gate's SQL Compare

I have a new tool in my toolbox of things I get to play--while being paid to do so.  This one is the SQL Compare utility from Red Gate. 

This tool is designed to allow a user to compare--and update-- the schema's between two disparate databases.

Which all I can say in regards to this is a hearty YAY!

After all, consider the project upon which I'm currently working, which is our CloudBuster Web Framework system. This project is basically the love-child between a standard .NET CRM utility and SharePoint.   It's a massive undertaking in Visual Studio, with roughly 20 discrete projects hiding within it, all as optimized for genericacy and ease of updating and extending as I can make them.

Anyways, we have roughly 25 clients on this framework so far. Some using it as internal intranets (the Sharepoint market space) and others using it as a CRM tool (the DotNetNuke/Joomla market space).

And this is while I'm performing active maintenance and development making the system better and more robust, and have more functions and all that sort of good jazz.

But, the point here is that that's roughly 25 databases that need to be synchronized every time I make a change to my development database or add in a new functionality.  And while the code base works fine for either database, it's a matter of allowing new functionality, even as older code gets refactored into newer and better paradigms that drive this need to occasionally synchronize database schemas.  Previously, this involved scripting out all the changes I could find between my development database and one of the in-production ones, and then running that script against every database, praying that a) I caught all the changes and b) none of these missing changes were breaking.  This meant visually comparing every database structure in every client database.  A process that took roughly 6 hours when I had to perform it against 15 databases back in May.

Well, I got SQL Compare, and was able to run it against all 25 databases over the course of 2 hours.  Two hours which included time to run backups of every database, as well as checking each client's application both before and after the update.

Fun, fun fun!

Thursday, August 18, 2011

Row Not Found...

We (as in the company I work for) have a product which we've named Bounce. Bounce is, as one might guess from the name, a product which reboots servers. It's a solution-in-a-box type thing, that comes in a 1u chassis for server racks.

This product is actual in production at a number of sites, including ours. Additionally, our site is the most complex of the various configurations out there, just because we have a couple of different production networks, our corporate networks, and a "development" network where those servers that use developers torture reside.

Regardless, there was a bug in Bounce, where it would randomly report a failure in one of the servers. Well, this little bug had been bothering the Network guys for a bit, and they finally brought it to my attention as well as the boss' attention--which resulted in some time scheduled to work on the issues, as well as add a few additional enhancements that had been hanging out on the drawing board for a while.

So, I started work, and tested the bounce group that the issue usually popped up in, and found, absolutely nothing.  Everything worked perfectly.

So, I chalked it up to gremlins, and implemented the system additions.

Well, I was doing some final system tests, when, lo and behold, the issue cropped up. I opened up the event log, and saw it somewhat flooded with the same message over, and over again, the only difference between those messages were the fact that it was being generated for every server configured in the system.

That error message read: row could not be found or updated.

Talk about useful.

So, I went to Google, and found some discussions that blamed one of two things:

  1. Concurrency issues generated by the "no count" flag being set on the SQL Server's default connection options
  2. A difference between the DBML definition of the table, and the actual underlying table
So, I checked both issues. I mean it's only a matter of moments to open up SQL Management Studio and ensure that no count wasn't checked, and only a bit harder to just flat out delete all the tables and views on the DBML and re-drag them into the designer.  Sadly, neither solution worked.

Since I was certain that the DBML looked just like the underlying tables (having just dragged them over) I looked more closely into the concurrency issues that folks are reporting.

And I realized that this isn't a SQL concurrency issue, basically, it's not a race condition where two requests are both trying to modify the table at the same time.  This is one of those other definitions for the word concurrency, specifically things being in accordance or agreement.

The below is basically what was happening:
Get List of Devices in BOUNCE QUEUE For Each Device in List
get ComputerDetails as LINQ object
Perform Bounce
Perform System Checks Function on ComputerObject
Update properties of ComputerDetails
Submit Changes on the DBML
What is important is the bolded line there.  That Perform System Checks Function was updating the COMPUTER DETAILS table via an EXECUTECOMMAND call on the DBML object. 

Basically, it was modifying the underlying data table, without updating the CompterDetails LINQ object.

This was fine until I actually updated the ComputerDetails LINQ object and then submitted it back to the database.  When I did that, the system performed a concurrency check (in the "in agreement" definition) against the actual row using those properties that were not being updated.  Since they had been modified elsewhere, outside of the normal LINQ-to-SQL paradigm, LINQ was unable to find the row--or at least upon finding it decided that "no, this wasn't really the row I was looking for."

This means, that it happily spat out a "Row not found" error.

I immediately thought up two possible solutions for what was happening, the first was to re-work the code to use the LINQ object in all those places where in-line SQL was being used.  The second was to re-work the one place I was submitting the LINQ object to use in-line SQL.   Being a lazy programmer, I happily took the latter option.

Lo an behold, my event logs are clean, the error has stopped presenting itself and all is happy and right with the world.  At least until the next bug.

Blog Widget by LinkWithin