Almost a decade ago I picked up a pair of relatively inexpensive Sound Dynamics R606 floor-standing speakers. Using the same components from their high-end line (I believe Mirage was the high-end marketing name), these were the poor-man's version. I still have them today, and they are extraordinary. I have never, anywhere, heard better sounding speakers overall, and I've either purchased or auditioned a large number of dramatically more expensive brands and models, and I've tried to follow the advice by a lot of audiophile magazine. Still, though, the voicing and realism of the reproduction that comes from the R606 is just unparalleled - I watched a DVD with them as the fronts for the first time recently, and the realism was absolutely spooky.
Of course like all speakers they aren't perfect - they can get a bit muddy for percussion in the lower range, and they aren't really suited to loud "rock" style music. Yet for other music, particularly of the female vocal genre, they are exemplary.
The only really point here is that with speakers, you don't necessarily get what you pay for: You might get much more, or much less. The only real consideration of a speaker's performance is to actually audition it.
In my prior entry, titled EXIF - Digital Photography and GPS, I opined that we would see a revolution in digital photography once digital cameras started utilizing the available GPS related tags in the EXIF data structures. I received a couple of great responses, including one by Luke Francl where he pointed me to two great links - Mappr!, which is a dynamic application that displays Flickr photos, geocoded based upon their user added tags (e.g. A flower with the keywords Seattle, Washington would appropriately display in Seattle), and Photospace, which is an application that logs GPS data on your PC, and then in "post processing", so to speak, it sets the geographical information on the images (by correlating times. e.g. a photo taken at 1:37pm correlates with an external GPS entry saying that you were at X & Y). A very nice stopgap solution until cameras themselves integrate this functionality.
[See also http://www.yafla.com/dforbes/2005/11/29.html#a201]
More often than not (depending upon context and teams) I prefer to fully qualify references, particularly in cases where there are any possibilites of collisions now or in the future (e.g. a lot of vaguely named data and business entities fall in this category, with nondescript names that could easily apply elsewhere). This just seems like good defensive programming, and yields code that isn't fragile. It won't shatter if someone adds a class to your namespace (or any other namespace that you're blindly using) that collides with a class in another namespace. For precisely the same reason I often preface instance references with this.
In this preference I am more of an exception than the rule, however - most prefer to add a using atop their namespace, and simply rely upon the compiler to sort things out. The premise being that the fewer characters exist in the code, the cleaner and more maintainable it is: If you can add a using System.Data.SqlClient to your file, then that namespace should never appear again. There is definitely a lot of validity to that position as well.
(Of course with something like the "CodeML" I described earlier, the XML would store the fully-qualified names, and developers can choose whether to display the qualified or unqualified names based upon their own preferences. It's just a display issue)
Many of the most time-consuming, polarizing debates in software development are the constant back-and-forths over trivial code style: Tabs or spaces, 2 or 3 spaces, curly bracket at the end of line or beginning of the next, and so on. While C# improves things a bit in that it, by default, does some formatting (such as curly bracket placement), they could have taken it a step further - the source should always be stored in a clear, defined and standardized XML storage format. e.g.
<namespace name="Microsoft.LameExample">
<class visibility="public" name="MyClass">
<method visibility="public" type="instance"
name="Run">
<call>
<method>System.Windows.Forms.MessageBox.Show</method>
<parameter>Hello!</parmaeter>
</call>
</method>
</class>
</namespace>
I'm hardly the first to advocate this (and of course it's what most of us thought about when we first started getting a handle on XML many moons ago - how can we apply this to software development), and while I thought I was original thinking up the term CodeML, there are actually already plenty of references to it out there. It's a pretty obvious idea.
With such a structure not only would language parsing be much easier for third-parties to interact with, but most importantly it would allow each user's environment to stylistically render the code however they want. Source control systems could (should) be schema aware, intelligently doing change management, and we wouldn't have massive change sets caused by someone running a reformatter to update to the standard of the day, switching from tabs to 3 spaces (python's use of whitespace to meaningfully indicate blocks/scope is absolutely brilliant, as an aside), or updating the curly bracket standard. What a complete waste of time and effort, and what a ridiculous distraction from actually solving problems.
Of course we still have the issue of case sensitivity - I'm still on the fence about this. I love C & C++, and I've always hung onto their case sensitivity out of habit ("real programmers pay attention to case"), yet it's possibly just another needless distraction. There really are very few instances where you want overlapped names, differing only by case.
It was, I think, an ugly decision to incorporate case sensitivity into .NET.
If there were no case sensitivity issues then this too could be an environmental option (e.g. all identifiers are stored in upper or lower case in the XML file, but then rendered according to user preferences - consts all upper case, parameters camel cased, public methods pascal cased, and so on. No need to "correct" such a menial thing in other people's code. The IDE knows what each of these things are and what their visibility is, so there should be no need to crystalize such a pseudo-Hungarian notation in our code).
This is of course just off-the-cuff thoughts after hearing yet another reformatting debate, so temper your criticism accordingly. I'm also pragmatic enough to realize that making a standardized schema for something with as many edge conditions and exceptional circumstances as source code isn't quite as easy as it sounds.
Many feathers have been ruffled regarding the State of Massachusetts backing the OpenDocument standard, demanding it as the primary document archival and working standard in the near future. This is, of course, in direct opposition to Microsoft's plans with their Office XML format, a relatively open and transparent interchange format that they banked much of their hopes for Office 12 upon. Turns out that some took issue with the fact that, while otherwise it is gratis and open, Microsoft's licence basically limits GPLd applications from joining the Office XML game (not explicitly, but rather simply through an incompatibility. It isn't as insidious as it sounds).
While it might not seem like that big of a deal that one relatively small state dictated such a change, these sorts of things are almost always contagious - it is extremely likely that many other governments and levels of government will follow suit. Microsoft will almost certainly have to support OpenDocument, or will have to completely unencumber Office XML (they're 99% there, though many say even that will be too little, too late). We've already seen Microsoft surprizingly include PDF output functionality (though that's not enough to satisfy the State of Massachusetts), so it doesn't seem like much of a reach for Microsoft to capitulate and add OpenDocument functionality (it's probably largely just a document mapping/transformation type problem).
Nonetheless, one comment on a message board had me reminiscing about where .DOC once was, and where it is today. The writer in question, to paraphrase, opined that one would be cutting off their own nose to spite their face if they were to relinquish their ability to deal with Office files. "How would they communicate with other people and organizations?" they asked. Without the Office formats as the lingua franca, the implication was, they would be lost in a sea of unreadable files!
If someone said that to me six years ago, I would have certainly agreed: every document - from resumes to financial statements to installation instructions to inter-organizational communications - were .doc files. It was the ubiquitous document format. Compare that to today: Now the vast majority of resumes are transmitted as plain-text, html, or by using some ardous online resume builder (which behind the scenes is being stored in some proprietary format, or perhaps hr-xml). Financial statements, and virtually all layout specific documents are relayed as PDFs. Many other communications occur in rich-text or HTML email. In most of the places you would once find a .DOC file, you now find something in its place. Of course those are documents meant to be consumed, and at the source Microsoft Word most likely played a part, but the fact remains that Word becomes irrelevant once the document is transformed into one of these consumable document formats. The network effect lock-in is largely a thing of the past.
If I had to pick a turning point - the moment when .doc jumped the shark - it would have to be the Melissa virus. Suddenly innocuous document layout files that could be easily viewed and printed became a vector of contamination, with caveats and disclaimers about their handling. At that time I was doing software development at an engineering shop, and worked with HR in vetting resumes. It was shortly thereafter that we started investigating alternatives to people emailing us Word files, and we certainly weren't alone.
Of course Excel remains a critical document format, and if you share numbers in the industry it's likely that you see an .XLS file along the way.
Today marks the one month anniversary of the beginning of this blog. During that period I've put up a ton of content - really I've used it more as a straightforward CMS than a blog (my prior manual content management process was a mess, and this is just a world better). I've been very happy with the process and the feedback, and the excellent response I've seen from the community, and I most certainly plan on continuing: One nice thing about constantly mulling over ideas, and being able to type quickly, is that it only takes a few moments a day to maintain this.
Furthermore, a robust comment system is in the testing stage and will be live imminently, and hopefully it will give users a lot more of a voice to agree or (more likely) disagree. It will probably make it a lot more entertaining (for both readers and myself).
Thanks for making it worthwhile.
Dennis