Made a bit of a fool of myself today, mistakingly implying that I was building webpages using brushed-aluminum backgrounds back in 1990 (my actual statement was that I was doing so "about 15 years ago", but I didn't actually think through what that would mean). In reality the date was closer to 1994, where I was building a little PC configuration tool for a retail computer shop (which was a component of a complex corporate structure that included a music store, home theatre equipment, and computer consulting and sales), allowing users to dynamically configure a PC and get a price (the server-side scripting was some innovative completely proprietary script), and then print out their config and bring it in to place an order.
The impetus for the discussion was the implication by an individual that if Microsoft used brush-metal backgrounds, clearly they're ripping off Apple (as Apple fanatics believe that Apple invented everything. I view Apple very favourable, but more times than not they're simply executing ideas better and more beautifully than people before them).
My reply was that brushed-metal backgrounds were some of the first uses of the BACKGROUND attribute: I fondly recall upgrading my PC configuration web "app" to use a classic brushed aluminum look. This was long before Apple started using brushed metals on their desktops. I was hardly an innovator, and such backgrounds were pretty common because they looked like something people could relate to in the real world, yet they could be low contrast and compatible with overlaid text. They are an obvious and inevitable background.
Outside of my chronology problem, what struck me as most disturbing was the impression some have about the state of computers in 1990 - that the ability for brushed-metal graphics to even exist was simply an impossibility. How absurd. In 1990 the Atari ST and Amiga, both very graphically rich PCs, had existed for a half-decade, and were certainly capable of creating and displaying a trivial brushed aluminum graphic. Apple was already up to the immensely powerful Apple IIfx (I lusted over ads for that "Wickedly Fast" PC). Windows was already out for 5 years, and Microsoft was already a billion dollar company. The WWW didn't exist, but a lot of us had been using bulletin board systems, and interconnected message systems (Fidonet, Usenet, and various others) for quite some time. While you couldn't run a Photoshop effect and generate a brushed metal, people would load up long-existing raster graphics programs and plug in the pixels to generate the desired effect.
The point, if there is one, is that Google didn't invent the internet, and Apple didn't invent graphics. This whole "computer thing" has been going on for a while.
I try to keep on top of the various important releases from Microsoft, testing assumptions and seeing what's new with each release. Tonight I decided to install the September 2005 CTP of Microsoft SQL Server 2005.
While it seems like a pretty trivial exercise to update to a new release - and from a difficulty perspective it is - it is remarkable how much time each of these iterations takes. While I don't need to sit here looking at the screen for the duration of the install, there nonetheless is a lot of user interaction that is necessary (even if it's just saying okay to random dialogs), and it soaks up PC resources for quite some time. First one performs all of the various deinstalls of the prior iteration, and the lengthy installs of the new one. Add in various incompatibilities just for fun. "Whoops, I have the Visual Studio July CTP .NET Framework, which is conflicting with the September CTP of SQL Server 2005". Almost sounds like ".dll hell". Of course to really keep on top, add in all of the CTPs of Visual Studio, and the other tools. You can basically fill your days uninstalling and installing various tools.
There is no real "point" here, and I can't see any possible solution (except for perhaps completely touchless installs that require zero interaction from setup.exe to finish), but it could be the reason why so few people seem to have any hands on experience with either SQL Server 2005, or Visual Studio 2005.
Several readers have written to me over the past while, asking for an update to an article that I wrote for the July, 2003 issue of MSDN Magazine. In that article, I expressed a lot of optimism for the future of Scalable Vector Graphics (SVG). However, based upon how the market has evolved since then, and the amazing clarity of hindsight, I have come to believe that SVG is effectively dead as a mainstream, desktop technology. To many this will be a painfully obvious fact, but I thought it had to be addressed (and it allows me to respond to queries with a courteous link).
SVG, as a quick primer, is a vector graphics technology that allows for gorgeous layered designs using basic primitives. SVG also offers a wonderful DOM programming facility to allow for animations and programmatic alterations - I won't go into SVG in technical detail (not only are there plenty of resources out there that do, but I also don't pretend to be an expert in SVG), but I will say that in a nutshell SVG is a standardized, owned-by-no-one alternative to Flash: With a simple XML layout and clear, logical specifications, SVG was compelling in its approachability and low barrier to entry - No special authoring kits, or understanding of convoluted binary formats, was required to begin creating dynamic, vector-graphic solutions.
Nonetheless, based upon some observations and occurrences since, I will confidently state that SVG is dead on the desktop:
These, along with other factors, have led me to believe that SVG on the desktop is a non-starter, barring some jarring schism in the marketplace. I think it's too little, too late for Firefox to offer a wide deployment of SVG, and I doubt Adobe is going to do much more than let SVG fade away (of course they'll claim otherwise, but let's be honest).
I do, however, continue to believe that SVG on the server, as a component of the image processing pipeline, is still entirely viable.
[UPDATE: A followup can be found here]
At the beginning of the year I published parts I and II of the SQL Server High Performance Series, promising Part III "soon". This series was very well received, and garnered some great feedback and encouragement, but then I got overloaded with other things (primarily the birth of my second child - my son Weston).
Well I have finally dedicated a bit of time, and plan on wrapping the series up over the next two weeks. While it isn't the most indepth or profound guide on designing for performance, it does contain tips and tricks that experience has shown me most database implementers (most of whom are part-time database designers by necessity) don't know.
Over the past couple of days there has been a lot of discussion regarding some new, higher density flash memory devices. While I don't think a doubling of density is all that remarkable or technology shifting (flash is still quite slow compared to a modern hard drive. This isn't to discount it, and there are a tremendous number of very valuable uses for such a solid-state, low-power technology, but just wanted to mention that it isn't a panacea and there are compromises), what fascinates me most about these sorts of discussions is the metrics articles use to help people understand capacity. The article linked above states that "By combining 16 of these, manufacturers get 32 Gb[GB - sic] of flash memory that can store more than 32 hours of HD video files, 8,000 digital music files (670 hours), or 200 years of daily papers.". Woo, 200 years of daily papers (all papers? One paper?). Remember when the standard metric was the number of copies of the King James Bible? I never knew how much space the Bible would actually require, but it sounded like a lot when something could hold multiple copies of it. [UPDATE: Looks like it's about 4.8MB uncompressed, so a 32GB flash card could hold 6,826 copies. Sounds impressive. But how many "Libraries of Congress" could it hold?].
As flash memory starts to compete with hard drives, operating systems will need to mildly adapt. For instance, flash has a limited lifespan, with localized degradation each time you erase a block: The common behaviour for operating systems to page out blocks of memory to the storage system unnecessarily, such that Windows does regularly, and to endlessly create and destroy small temporary files on the filesystem. Either wouldn't be a wise thing to do with flash. It will be a good thing as operating systems adapt, as I'd love for my hard drive to actually power down when I'm not doing something that actually requires its involvement.
As, err, "regular readers" know, I just started this blog a week and a half ago. Since then I'm up to around 400 visitors a day in here, which I'm pretty satisfied with given the limited amount of content thus far (though I think it's pretty good for a week and a half! Apart from a couple of dedicated, focused efforts, most of this has been off the cuff commentary, but it really adds up quickly. I could imagine the corpus of info that will exist here in a year).
Nonetheless, I would like more traffic, to the point that I'm saying "Scoble? Who's that?".
One of the ways to drive traffic to a site is through the use of Trackbacks. This mechanism, at its root, is a quid pro quo arrangement between blogs - e.g. I post a brief summary of something a "big" blogger said, and then ping their site with a trackback. They post the trackback link and users, and search engines (and PageRank if nofollows isn't put into force), go both ways. You pat my back, I'll pat yours. As mentioned in a prior posting, I currently don't have trackbacks or comments because of the slowness of the Radio Userland servers, not to mention that it would be a hassle to monitor it for spamming. I investigated implementing my own trackback server (it's a very simple spec), but the current industry belief seems to be that trackbacks are dead because of spam (which is a funny claim, because trackbacks are pretty much by design a type of targetted spam).
So for the meantime I am going to continue to monitor referral logs, as I always have, and if I notice someone coming from a link or post on your site, and I can validate that it's real, then I'll add a note on the posting. Basically it's a manual trackback system.