Web 2.0 is a term that's getting more and more attention these days. Not only positive press by the fawning sheep who think they've personally discovered something amazing and need to bring it to the unwashed, but a lot of negative commentary as well. 

What is Web 2.0? Well it depends on who you talk to - it could be service oriented web technologies (if NTP ran on HTTP, we could call it Web 2.0 pre-1985), community collaboration (e.g. Wikis like wikipedia, group tagging like flickr, etc), or a richer environment courtesy of the more prevalent use of more advanced technologies (like, cough, AJAX - some people, hanging onto Google Suggest's coattails, decided that it was important that they declare a terminology for this "new" technology that had actually been in use for over half a decade).

That last point deserves a bit of attention - why is it that recently some great web applications like Google Maps and Flickr have appeared, offering so much more usability than their predecessors? What technological revolution occurred to make this happen? Did AJAX just get discovered by some researchers who found some magical new way of making browsers sing?

...we've had the so-called AJAX for years, and it has been in use by intranet web teams since the late-90s/early-00s...

The answer, of course, is that we've had the so-called AJAX for years, and it has been in use by intranet web teams since the late-90s/early-00s. It was, however, primarily the domain of teams that could mandate that their userbase would use Internet Explorer, as that browser was the leader (by far - you don't have to love Microsoft to acknowledge this reality) as an interactive web application platform. I had the luxury of making such a declaration, and was developing monitoring and control web applications that used XML data islands, msxml's XMLHttpRequest, client side XML transformations on demand with changing parameters based upon user input, layered transparent graphics for usability, and so on: In real-time you could monitor the status of tens of giant power generators across the continent, and with a click of a button - well along with a confirmation - you could control them. This was about 5 or 6 years ago. I was hardly unique - in fact I've never even considered myself a web developer, and this was just a one-off style solution where the web interface was the best choice, so I took a breather from back-end/database development to build this solution.

So why didn't the technology take off on mainstream websites? One simple reason - Netscape 4.x. Quite a few corporations stuck with their decision to back Netscape in the browser wars - which they backed largely for its theoretical cross-platform advantages - even after Netscape was terribly obsolete and basically dead (for example I did some work for Bell Canada a couple of years ago, and the desktop standard throughout the entire organization was Netscape 4.x. Of course many users figured out where to find the hidden iexplore.exe icon and covertly used it instead). If you made a public website where you couldn't reasonably mandate a particular browser, you developed for the lowest common denominator, and that denominator was Netscape 4.x (even if you had 0 visitors using that browser, it was just good practice to avoid tying to Microsoft's software, so you targeted the cross-platform leader. That leader was Netscape).

Now, of course, the big competitor is Mozilla cum Firefox. Featuring modern DHTML capabilities, XMLHttpRequest functionality, and most of the other major web app functions, and offering full cross-platform functionality, Mozilla completely changed the landscape. Suddenly the "lowest common accessible denominator" was pretty powerful, so there is no reason to hold back empowering your site.

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.

XML does not equal open and transparent.

Binary* does not equal closed and proprietary.

*-An ambiguous term that most people use to mean "not XML"