Two huge releases from Microsoft were RTMd today, and were immediately made available on MSDN Subscriber Downloads: SQL Server 2005 and Visual Studio 2005. This is very good news, and delivering over a week before expectations is a wonderful PR move (although, to be fair, in the grand scheme of things they're both terribly late).
While their application servers are encountering some load issues, I managed to download both of those products (coming in at 2.7GB each) in about 2 and a half hours on a home cable modem connection (Cogeco is a great provider). Microsoft must have some incredible bandwidth feeding Redmond.
Two quick comments:
Otherwise everything went very smoothly, and it looks good.
Here's a scenario that many developers have faced: You finish work for the night or whatever, and take advantage of the downtime by running an install of some sort of product that integrates itself within MSDN Help (usually other Microsoft tools or technologies). Presumably its addition sets a dirty bit in the help indicating that the index and search corpus needs to be rebuilt.
The next day you're programming away, and then realize that you need the docs for Xyz. You launch the MSDN Library, to be met by a help update in progress dialog. In recent iterations this can take many minutes to complete (I've timed it at over 15 minutes in some scenarios), during which you have no access to the help, and your PC is overloaded. Generally one doesn't plan downtime around the launching of help, so this is entirely disruptive.
What an annoying oversight. It's pretty clear the indexing should happen during an actual downtime activity (e.g. installing), at the very least as a checkbox option. Back-end loading it like that, as a suprize to be unleashed at the most inconvenient of times, is a very, very poor design decision.
The topic of email vs. face-to-face came up after seeing a humorous entry on another blog (which I, of course, now can't find), and this has long been a topic of interest so I thought I'd post an entry.
Scenario: You're working for a small firm, working in a pungent, medium-sized room that you share with a coworker, developing software for the remote-controlled toothbrush industry.
You need to ask your coworker a question.
Do you:
Change the scenario a bit so instead you're providing a bit of information to your coworker: Maybe you're telling them about a source code change that you made, or you're answering a question they asked you earlier, but you've only now found the answer. Would these situations change your answer?
Many would immediately answer 1. Regardless of the context, where physical proximity is available it is the first choice.
In fact, not only would this be their personal preference, they would perceive it as a significant fault to choose otherwise. "What sort of maladjusted person would email the person sitting right beside them?" they might rhetorically ask.
I've come across this quite a few times in my career. Several times I've heard it said about others, and other times I've had it pointed out as a fault in my own behaviour (I'm a fan of email, and I type quickly so I often resort to it).
To those people I would say - You don't understand email.
Email is not simply a second-rate substitute when a face-to-face isn't possible. Email has several significant advantages, including, but not limited to:
Imagine if your utility company didn't mail you a bill, but instead they gave you a phone call every month telling you your total. You're eating dinner and the phone call comes in.
"Hi Mr. Jones! Boy you really went wild with the hottub last month! The details of your bill are XYZ and YZX and your meter was read XZY and your grand total is $YYY and you need to pay by YYYY-MM-DD"
Of course this is ridiculous, as contrived analogies usually are. And of course you probably want a better relationship with your coworkers than you do with your utility company, so it really shouldn't be considered too analagous. But the basic premise remains the same - a bill in the mail can be dealt with at the recipient's own pace, at a time appropriate for them, and clearly and concisely contains the necessary details. Your utility can't say "Uh uh! I said that your total was $2Y. You must not have been listening carefully. Here's your penalty."
I'm not completely polarized - there are many scenarios where a good face-to-face is preferrable, and it is necessary to have them frequently to maintain good friendships and a robust casual communication network in the office. Nonetheless, the misplaced moral righteousness of the anti-email crusaders is, in my opinion, a misunderstanding of the place and purpose of email.
The other common criticism of email is the oft recounted "emails don't convey emotions well enough - 90% of communications is non-verbal you know! - so people get their hairs up". There is some proven truth to this, and it is entirely true that some sensitive discussions can get out of hand in email. Yet there is another, mysterious side to email that's often ignored: Many of those sensitive-in-email discussions would never have happened verbally. Maybe it seems like an acrimonious waste of time when a couple of alpha-developers have a long, drawn out debate about some technical errata, but the reality is that often there are things learned from them (as polarized as people may seem, they do often incorporate new knowledge).
Many of these sorts of debates would never have happened outside of the venue of email, so it isn't that email made the conversation more polarized or impersonal, but rather email gave an outlet for communications that otherwise would have simmered unspoken. Poor practices would be continued, options ignored, and so on, all uncontested.
Okay, I'm being facetious in the title.
I knew at the outset that there was no reason for the server side processing, but I was avoiding the minor - but still of substance (e.g. an hour of my life) - creation of JavaScript code for the colour space conversions. I finally got a moment to hash that together tonight, so the page now allows for colour changes and variations entirely on the client side, with no post backs. I contemplated keeping the post-backs to have dubious functionality like "here's the colours that other users are creating!" but realized that would be pretty silly.
Visit yaflaColor today for all of your colour matching and scaling needs. I've tested with IE, Opera and Mozilla/Firefox, and it works successfully in those, but your mileage will vary (as it does depend upon DHTML and some less-standard elements of JavaScript). [UPDATE: After several updates more, I'm extremely satisfied with the results. Basically the only change that I still might do is improving the aesthetics of the sliders to rounded inlaid sliders, but otherwise it completely scratches my itch).
The tool actually served a really unintended, but valuable, purpose - My 2 1/2 year old daughter saw me testing it and asked to "play the color game". I hooked up a mouse and she was off and running, announcing the colour and then selecting it, celebrating on each new colour.
Many web applications insist that inputted data follow a precisely prescribed, often unintuitive, form: Phone numbers have to use an exact layout ("Do not enter parenthesis or dashes in phone number!"), or postal codes can't have spaces ("Enter postal code as A#A#A#! Do not enter a space!").
While sometimes these rules conform to common norms, many times they're completely inexcusable, arbitrary choices on the part of a very-lazy programmer or GUI developer.
I've come across this countless times, but it came to the forefront while I looked at "competitors" to the trivial yaflaColor (which is a micro-utility to solve my own need to easily and quickly get colour scales for theming). One such alternative included a box where you could punch in the hex color, and out would pop a color theme. Aside the hex color box, and as a pop-up, was the warning "DO NOT ENTER THE #!" (as web colours are usually prefaced with a #, they clearly knew that many users would input this form).
Really - What takes longer: Writing a single line of code to parse out the #, or forcing every single user to read and understand that warning, and possible alter what they were going to put in there (e.g. if they were just going to paste in web colors it would be a no go - now they have to edit each of them)? Why in the world would someone choose the route of refusing such a ridiculously trivial allowance?
Yet sadly this is entirely too common: Too many times I've been forced to remove (or add) spaces in inputs that have zero possible impact on the preciseness or ambiguity of the input.
To save the developer a tiny amount of time, countless users are forced to waste their time.
I like Unix. Not only do I regularly run Linux (a Unix clone) in a virtual machine, for years my firewall/internet services gateway ran the superlative FreeBSD (to finally be replaced by a solid state device running an embedded version of Linux). Unix-style command line utilities are a staple of my day to day computer use.
Nonetheless, many of the loudest people who associate themselves with Unix, Linux, or open-source in general are intolerable.
Case in point: http://blogs.technet.com/windowsserver/archive/2005/10/28/413255.aspx (read the comments, and the similar comments in the Slashdot discussion)
So Microsoft decided, for whatever reason (possibly just a changing shift in their development-group mindset), that symlinks are now a good choice, and this is the sort of response they get. This, sadly, is typical.
I've received this sort of feedback myself as well. For instance I received the following email in regards to an article I wrote for MSDN magazine (one about SVG graphics, in which I talked about the compressibility of SVGs via the specification's inclusion of GZIP - GZIP the standard, not gzip the product. GZIP, and the implementation gzip, is basically a wrapper around Lempel-Ziv compression, though strangely the critic didn't feel the need to acknowledge them)
"Thankfully, the SVG standard includes native support for GZIP compression (a standard documented in RFC 1952) . . ."
This is certainly correct, as far as it goes. However, you neglected to mention that "gzip" is one of a number of GNU utilities, the main branch of Open Source development. The authors of "gzip" are Jean-loup Gailly <JLOUP@GZIP.ORG>, and Mark Adler.
While not strictly necessary, it would have been nice to mention that "gzip" came from outside the MS Windows world. It is somewhat disturbing that Windows developers, and in at least one instance, Microsoft itself, use Open Source code without crediting the source.
This was in response to an article I wrote advocating the open W3C scalable vector graphics format, providing all source code with BSD licensing, and including more links and references to open source projects than you're normally going to find in an MSDN article.
Nonetheless, I was the "enemy" to this guy.