I registered that domain some time ago, primarily as a publishing location of various SQL Server articles that I've self-published. Since then I've gotten a tonne of interest by people who'd like to contribute (people who know me and like my stuff), mostly people irritated seeing it sitting idle (I've had far too much on my plate for a while).
As such, today I switched http://www.professionalsqlserver.com over to a MediaWiki (the powerful platform that Wikipedia runs atop), though it'll take a while for the DNS change to fully propagate. It should make for interesting times, and I hope to learn a lot about online collaboration, and about the MediaWiki platform. Right now it's a bit of a mess, but I tend to exploit and master these things pretty quickly, so watch for it to get really exciting quickly.
I've added several entertaining surveys to go along with entries on here over the past couple of weeks, and have gotten a great response, however some users have questioned why they immediately get the results for the survey without the ability to pick a choice themselves.
This can happen for several reasons-
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.